RAST Summary

Rule Name Total Violations
DCL00J 0
DCL01-J 0
DCL02-J 10
EXP02-J 35
ERR02-J 48
ERR04-J 3
ERR05-J 951
ERR07-J 392
ERR08-J 50
FIO02-J 72
LCK01-J 0
LCK02-J 0
MET09-J 0
MSC00-J 5
MSC01-J 0
MSC02-J 16
NUM07-J 2
NUM09-J 4
NUM10-J 0
OBJ09-J 1
OBJ10-J 181
SER05-J 2



Total 6171 directories searched and 4406 files scanned. Out of the above rules, 1772 CERT violations are reported




Following files have secure coding violations

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/lib/mapapi/com/android/bluetooth/mapapi/BluetoothMapEmailProvider.java

Rule Standard Line number
ERR05-J CERT 335

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 335 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 416

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 416 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 462

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 462 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 516

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 516 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 617

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 617 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 665

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 665 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/lib/mapapi/com/android/bluetooth/mapapi/BluetoothMapIMProvider.java

Rule Standard Line number
ERR05-J CERT 221

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 221 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 267

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 267 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 354

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 354 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 532

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 532 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 632

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 632 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/btservice/AdapterService.java

Rule Standard Line number
ERR05-J CERT 2072

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2072 A method invocation debugLog("IOException closing a file after writing the profile status") is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/gatt/GattDebugUtils.java

Rule Standard Line number
OBJ09-J CERT 128

OBJ09-J. Compare classes and not class names

There is no requirement that class names be unique, only that they are unique within a package. Therefore trying to determine an object's type based on its class name is an exercise fraught with danger. One of those dangers is that a malicious user will send objects of the same name as the trusted class and thereby gain trusted access.

In the given program line number 128 code block uuid.getClass().getName().equals("java.lang.String") trying to compare classes and not class names

Non-compliant Solution

This non-compliant code example compares the name of the class of object auth to the string "com.application.auth.DefaultAuthenticationHandler"

public class Demo {
   
  public Demo() {
	  //some code
  }
 
  public static void main(String[] args) {
	  Demo d=new Demo();
	  if (d.getClass().getName().equals(
		      "com.application.auth.DefaultAuthenticationHandler")) {
		   // ...
		}
  }
}

Compliant Solution

This compliant solution compares the class object auth to the class object for the canonical default authentication handler

public class Demo {
   
  public Demo() {
	  //some code
  }
 
  public static void main(String[] args) {
	  Demo d=new Demo();
	  if (d.getClass() == com.application.auth.DefaultAuthenticationHandler.class)
	   {
		   // ...
		}
  }
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/hdp/HealthService.java

Rule Standard Line number
EXP02-J CERT 458

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 458 code block chan.mDevice.equals(device) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

DCL00-J CERT 758

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 758 have DCL00-J because chan.mDevice.equals(device) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/BluetoothMapAccountLoader.java

Rule Standard Line number
ERR05-J CERT 186

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 186 A method invocation mProviderClient.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/BluetoothMapbMessage.java

Rule Standard Line number
OBJ10-J CERT 41

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 41 code block public static int INVALID_VALUE=-1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/BluetoothMapContent.java

Rule Standard Line number
ERR05-J CERT 1070

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1070 A method invocation contacts.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1139

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1139 A method invocation contacts.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1214

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1214 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1314

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1314 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1348

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1348 A method invocation cr.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1376

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1376 A method invocation cr.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1403

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1403 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2263

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2263 A method invocation imCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2296

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2296 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2310

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2310 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2326

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2326 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2344

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2344 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2380

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2380 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2396

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2396 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2415

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2415 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2435

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2435 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2676

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2676 A method invocation smsMmsCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2764

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2764 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2861

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2861 A method invocation imEmailCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3345

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3345 A method invocation close(p) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3366

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3366 A method invocation close(q) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3443

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3443 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3487

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3487 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3519

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3519 A method invocation close(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3599

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3599 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3667

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3667 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3725

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3725 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3871

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3871 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3831

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3831 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR08-J CERT 3856

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 3856 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR05-J CERT 3988

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3988 A method invocation contacts.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/BluetoothMapContentObserver.java

Rule Standard Line number
ERR05-J CERT 1164

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1164 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1188

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1188 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1215

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1215 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1263

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1263 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1406

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1406 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1562

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1562 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1719

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1719 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1984

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1984 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2124

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2124 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2174

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2174 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2207

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2207 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2251

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2251 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR08-J CERT 2445

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 2445 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR05-J CERT 2556

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2556 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2659

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2659 A method invocation queryResult.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2734

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2734 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3063

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3063 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3238

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3238 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3263

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3263 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/BluetoothMapConvoListing.java

Rule Standard Line number
ERR05-J CERT 164

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 164 A method invocation xmlDocument.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/BluetoothMapFolderElement.java

Rule Standard Line number
ERR05-J CERT 330

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 330 A method invocation xmlDocument.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/BluetoothMapObexServer.java

Rule Standard Line number
ERR05-J CERT 284

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 284 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR08-J CERT 525

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 525 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 756

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 756 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/BluetoothMapSettingsDataHolder.java

Rule Standard Line number
OBJ10-J CERT 21

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 21 code block public static HashMap mCheckedChilds=new HashMap(); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/BluetoothMapSmsPdu.java

Rule Standard Line number
OBJ10-J CERT 51

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 51 code block public static int SMS_TYPE_GSM=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 52

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 52 code block public static int SMS_TYPE_CDMA=2; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

MSC02-J CERT 471

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 471 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/BluetoothMnsObexClient.java

Rule Standard Line number
ERR05-J CERT 386

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 386 A method invocation e.getMessage() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/map/SmsMmsContacts.java

Rule Standard Line number
ERR05-J CERT 89

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 89 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 133

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 133 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 191

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 191 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/ObexServerSockets.java

Rule Standard Line number
ERR07-J CERT 106

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 106 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/opp/BluetoothOppLauncherActivity.java

Rule Standard Line number
ERR05-J CERT 337

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 337 A method invocation e.printStackTrace() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR02-J CERT 326

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 326 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 337

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 337 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/opp/BluetoothOppObexClientSession.java

Rule Standard Line number
ERR08-J CERT 499

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 499 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/opp/BluetoothOppReceiveFileInfo.java

Rule Standard Line number
ERR05-J CERT 107

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 107 A method invocation metadataCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
MSC02-J CERT 229

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 229 code block new Random(SystemClock.uptimeMillis()) trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/opp/BluetoothOppRfcommListener.java

Rule Standard Line number
MSC00-J CERT 88

MSC00-J. Use SSLSocket rather than Socket for secure data exchange

Programs must use the javax.net.ssl.SSLSocket class rather than the java.net.Socket class when transferring sensitive data over insecure communication channels. The class SSLSocket provides security protocols such as Secure Sockets Layer/Transport Layer Security (SSL/TLS) to ensure that the channel is not vulnerable to eavesdropping and malicious tampering.

In the given program line number 88 code block Use SSLSocket rather than Socket use SSLSocket rather than Socket for secure data exchange

Non-compliant Solution

This noncompliant code example shows the use of regular sockets for a server application that fails to protect sensitive information in transit. The insecure code for the corresponding client application follows the server's code.

 
class EchoServer {
  public static void main(String[] args) throws IOException {
    ServerSocket serverSocket = null;
    try {
      serverSocket = new ServerSocket(9999);
      Socket socket = serverSocket.accept();
      PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
      BufferedReader in = new BufferedReader(
          new InputStreamReader(socket.getInputStream()));
      String inputLine;
      while ((inputLine = in.readLine()) != null) {
        System.out.println(inputLine);
        out.println(inputLine);
      }
    } finally {
      if (serverSocket != null) {
        try {
          serverSocket.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}
 
 

Compliant Solution

This compliant solution uses SSLSocket to protect packets using the SSL/TLS security protocols:

 
class EchoServer {
  public static void main(String[] args) throws IOException {
    SSLServerSocket sslServerSocket = null;
    try {
      SSLServerSocketFactory sslServerSocketFactory =
          (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
      sslServerSocket = (SSLServerSocket) sslServerSocketFactory.
                        createServerSocket(9999);
      SSLSocket sslSocket = (SSLSocket) sslServerSocket.accept();
      PrintWriter out = new PrintWriter(sslSocket.getOutputStream(),true);
      BufferedReader in = new BufferedReader(
          new InputStreamReader(sslSocket.getInputStream()));
      String inputLine;
      while ((inputLine = in.readLine()) != null) {
        System.out.println(inputLine);
        out.println(inputLine);
      }
    } finally {
      if (sslServerSocket != null) {
        try {
          sslServerSocket.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/opp/BluetoothOppSendFileInfo.java

Rule Standard Line number
ERR05-J CERT 129

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 129 A method invocation metadataCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/opp/BluetoothOppService.java

Rule Standard Line number
ERR05-J CERT 1014

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1014 A method invocation mConnection.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/opp/BluetoothOppTransfer.java

Rule Standard Line number
MSC00-J CERT 567

MSC00-J. Use SSLSocket rather than Socket for secure data exchange

Programs must use the javax.net.ssl.SSLSocket class rather than the java.net.Socket class when transferring sensitive data over insecure communication channels. The class SSLSocket provides security protocols such as Secure Sockets Layer/Transport Layer Security (SSL/TLS) to ensure that the channel is not vulnerable to eavesdropping and malicious tampering.

In the given program line number 567 code block Use SSLSocket rather than Socket use SSLSocket rather than Socket for secure data exchange

Non-compliant Solution

This noncompliant code example shows the use of regular sockets for a server application that fails to protect sensitive information in transit. The insecure code for the corresponding client application follows the server's code.

 
class EchoServer {
  public static void main(String[] args) throws IOException {
    ServerSocket serverSocket = null;
    try {
      serverSocket = new ServerSocket(9999);
      Socket socket = serverSocket.accept();
      PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
      BufferedReader in = new BufferedReader(
          new InputStreamReader(socket.getInputStream()));
      String inputLine;
      while ((inputLine = in.readLine()) != null) {
        System.out.println(inputLine);
        out.println(inputLine);
      }
    } finally {
      if (serverSocket != null) {
        try {
          serverSocket.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}
 
 

Compliant Solution

This compliant solution uses SSLSocket to protect packets using the SSL/TLS security protocols:

 
class EchoServer {
  public static void main(String[] args) throws IOException {
    SSLServerSocket sslServerSocket = null;
    try {
      SSLServerSocketFactory sslServerSocketFactory =
          (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
      sslServerSocket = (SSLServerSocket) sslServerSocketFactory.
                        createServerSocket(9999);
      SSLSocket sslSocket = (SSLSocket) sslServerSocket.accept();
      PrintWriter out = new PrintWriter(sslSocket.getOutputStream(),true);
      BufferedReader in = new BufferedReader(
          new InputStreamReader(sslSocket.getInputStream()));
      String inputLine;
      while ((inputLine = in.readLine()) != null) {
        System.out.println(inputLine);
        out.println(inputLine);
      }
    } finally {
      if (sslServerSocket != null) {
        try {
          sslServerSocket.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/opp/Constants.java

Rule Standard Line number
OBJ10-J CERT 275

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 275 code block public static String filename_SEQUENCE_SEPARATOR="-"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/opp/TestActivity.java

Rule Standard Line number
MSC00-J CERT 394

MSC00-J. Use SSLSocket rather than Socket for secure data exchange

Programs must use the javax.net.ssl.SSLSocket class rather than the java.net.Socket class when transferring sensitive data over insecure communication channels. The class SSLSocket provides security protocols such as Secure Sockets Layer/Transport Layer Security (SSL/TLS) to ensure that the channel is not vulnerable to eavesdropping and malicious tampering.

In the given program line number 394 code block Use SSLSocket rather than Socket use SSLSocket rather than Socket for secure data exchange

Non-compliant Solution

This noncompliant code example shows the use of regular sockets for a server application that fails to protect sensitive information in transit. The insecure code for the corresponding client application follows the server's code.

 
class EchoServer {
  public static void main(String[] args) throws IOException {
    ServerSocket serverSocket = null;
    try {
      serverSocket = new ServerSocket(9999);
      Socket socket = serverSocket.accept();
      PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
      BufferedReader in = new BufferedReader(
          new InputStreamReader(socket.getInputStream()));
      String inputLine;
      while ((inputLine = in.readLine()) != null) {
        System.out.println(inputLine);
        out.println(inputLine);
      }
    } finally {
      if (serverSocket != null) {
        try {
          serverSocket.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}
 
 

Compliant Solution

This compliant solution uses SSLSocket to protect packets using the SSL/TLS security protocols:

 
class EchoServer {
  public static void main(String[] args) throws IOException {
    SSLServerSocket sslServerSocket = null;
    try {
      SSLServerSocketFactory sslServerSocketFactory =
          (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
      sslServerSocket = (SSLServerSocket) sslServerSocketFactory.
                        createServerSocket(9999);
      SSLSocket sslSocket = (SSLSocket) sslServerSocket.accept();
      PrintWriter out = new PrintWriter(sslSocket.getOutputStream(),true);
      BufferedReader in = new BufferedReader(
          new InputStreamReader(sslSocket.getInputStream()));
      String inputLine;
      while ((inputLine = in.readLine()) != null) {
        System.out.println(inputLine);
        out.println(inputLine);
      }
    } finally {
      if (sslServerSocket != null) {
        try {
          sslServerSocket.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}
 

Additional information

Related Guidelines

ERR02-J CERT 527

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 527 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 524

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 524 code block e1.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

MSC00-J CERT 568

MSC00-J. Use SSLSocket rather than Socket for secure data exchange

Programs must use the javax.net.ssl.SSLSocket class rather than the java.net.Socket class when transferring sensitive data over insecure communication channels. The class SSLSocket provides security protocols such as Secure Sockets Layer/Transport Layer Security (SSL/TLS) to ensure that the channel is not vulnerable to eavesdropping and malicious tampering.

In the given program line number 568 code block Use SSLSocket rather than Socket use SSLSocket rather than Socket for secure data exchange

Non-compliant Solution

This noncompliant code example shows the use of regular sockets for a server application that fails to protect sensitive information in transit. The insecure code for the corresponding client application follows the server's code.

 
class EchoServer {
  public static void main(String[] args) throws IOException {
    ServerSocket serverSocket = null;
    try {
      serverSocket = new ServerSocket(9999);
      Socket socket = serverSocket.accept();
      PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
      BufferedReader in = new BufferedReader(
          new InputStreamReader(socket.getInputStream()));
      String inputLine;
      while ((inputLine = in.readLine()) != null) {
        System.out.println(inputLine);
        out.println(inputLine);
      }
    } finally {
      if (serverSocket != null) {
        try {
          serverSocket.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}
 
 

Compliant Solution

This compliant solution uses SSLSocket to protect packets using the SSL/TLS security protocols:

 
class EchoServer {
  public static void main(String[] args) throws IOException {
    SSLServerSocket sslServerSocket = null;
    try {
      SSLServerSocketFactory sslServerSocketFactory =
          (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
      sslServerSocket = (SSLServerSocket) sslServerSocketFactory.
                        createServerSocket(9999);
      SSLSocket sslSocket = (SSLSocket) sslServerSocket.accept();
      PrintWriter out = new PrintWriter(sslSocket.getOutputStream(),true);
      BufferedReader in = new BufferedReader(
          new InputStreamReader(sslSocket.getInputStream()));
      String inputLine;
      while ((inputLine = in.readLine()) != null) {
        System.out.println(inputLine);
        out.println(inputLine);
      }
    } finally {
      if (sslServerSocket != null) {
        try {
          sslServerSocket.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/pbap/BluetoothPbapCallLogComposer.java

Rule Standard Line number
ERR05-J CERT 132

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 132 A method invocation mCursor.moveToNext() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/pbap/BluetoothPbapObexServer.java

Rule Standard Line number
OBJ10-J CERT 156

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 156 code block public static int ORDER_BY_INDEXED=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 158

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 158 code block public static int ORDER_BY_ALPHABETICAL=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 160

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 160 code block public static boolean sIsAborted=false; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 709

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 709 A method invocation closeStream(outputStream,op) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/pbap/BluetoothPbapUtils.java

Rule Standard Line number
OBJ10-J CERT 51

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 51 code block public static int FILTER_PHOTO=3; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 52

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 52 code block public static int FILTER_TEL=7; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 53

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 53 code block public static int FILTER_NICKNAME=23; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/pbap/BluetoothPbapVcardManager.java

Rule Standard Line number
ERR05-J CERT 178

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 178 A method invocation contactCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 199

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 199 A method invocation callCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 242

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 242 A method invocation callCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 283

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 283 A method invocation contactCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 325

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 325 A method invocation contactCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 377

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 377 A method invocation callsCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 428

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 428 A method invocation contactCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 458

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 458 A method invocation contactCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 606

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 606 A method invocation buffer.onTerminate() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 661

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 661 A method invocation buffer.onTerminate() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/sap/SapServer.java

Rule Standard Line number
ERR05-J CERT 474

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 474 A method invocation msg.sendToTarget() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR08-J CERT 410

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 410 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/sdp/SdpManager.java

Rule Standard Line number
ERR07-J CERT 528

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 528 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 557

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 557 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 588

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 588 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 617

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 617 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 640

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 640 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 655

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 655 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Bluetooth/src/com/android/bluetooth/Utils.java

Rule Standard Line number
ERR05-J CERT 222

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 222 A method invocation Binder.restoreCallingIdentity(ident) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 256

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 256 A method invocation Binder.restoreCallingIdentity(ident) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/addbookmark/FolderSpinner.java

Rule Standard Line number
ERR07-J CERT 51

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 51 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/AddBookmarkPage.java

Rule Standard Line number
ERR05-J CERT 1151

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1151 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/FetchUrlMimeType.java

Rule Standard Line number
ERR05-J CERT 93

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 93 A method invocation connection.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/GoogleAccountLogin.java

Rule Standard Line number
ERR05-J CERT 154

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 154 A method invocation connection.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/homepages/RequestHandler.java

Rule Standard Line number
ERR05-J CERT 75

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 75 A method invocation cleanup() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 144

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 144 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
DCL00-J CERT 165

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 165 have DCL00-J because t.assignLoop("files",new ListEntityIterator(){ int index=-1; @Override public void writeValue( OutputStream stream, String key) throws IOException { File f=files[index]; if ("name".equals(key)) { stream.write(f.getName().getBytes()); } if ("url".equals(key)) { stream.write(("file://" + f.getAbsolutePath()).getBytes()); } if ("type".equals(key)) { stream.write((f.isDirectory() ? "dir" : "file").getBytes()); } if ("size".equals(key)) { if (f.isFile()) { stream.write(readableFileSize(f.length()).getBytes()); } } if ("last_modified".equals(key)) { String date=DateFormat.getDateTimeInstance(DateFormat.SHORT,DateFormat.SHORT).format(f.lastModified()); stream.write(date.getBytes()); } if ("alt".equals(key)) { if (index % 2 == 0) { stream.write("alt".getBytes()); } } } @Override public ListEntityIterator getListIterator( String key){ return null; } @Override public void reset(){ index=-1; } @Override public boolean moveToNext(){ return (++index) < files.length; } } ) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/BrowserBackupAgent.java

Rule Standard Line number
ERR05-J CERT 78

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 78 A method invocation in.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 161

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 161 A method invocation tmpfile.delete() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 150

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 150 A method invocation in.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 161

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 161 code block tmpfile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

ERR05-J CERT 203

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 203 A method invocation out.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 220

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 220 A method invocation out.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/BrowserBookmarksPage.java

Rule Standard Line number
ERR05-J CERT 638

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 638 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/UrlHandler.java

Rule Standard Line number
ERR05-J CERT 278

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 278 A method invocation cur.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/view/BookmarkExpandableView.java

Rule Standard Line number
ERR07-J CERT 105

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 105 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/UploadHandler.java

Rule Standard Line number
ERR07-J CERT 159

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 159 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 166

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 166 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/Bookmarks.java

Rule Standard Line number
ERR05-J CERT 129

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 129 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/provider/BrowserProvider.java

Rule Standard Line number
ERR05-J CERT 206

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 206 A method invocation searchClientIdCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 363

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 363 code block gearsFiles[i].delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 381

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 381 code block files[i].delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 381

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 381 code block files[i].delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

ERR05-J CERT 441

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 441 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/provider/BrowserProvider2.java

Rule Standard Line number
ERR05-J CERT 581

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 581 A method invocation helper.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 711

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 711 A method invocation preloads.recycle() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 730

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 730 A method invocation is.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 749

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 749 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1264

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1264 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1412

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1412 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1566

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1566 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1638

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1638 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1663

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1663 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1855

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1855 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1870

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1870 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1984

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1984 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2050

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2050 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/provider/SnapshotProvider.java

Rule Standard Line number
FIO02-J CERT 131

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 131 code block oldPath.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 131

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 131 code block oldPath.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 131

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 131 code block oldPath.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/provider/SQLiteContentProvider.java

Rule Standard Line number
ERR05-J CERT 118

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 118 A method invocation mDb.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 141

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 141 A method invocation mDb.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 161

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 161 A method invocation mDb.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 184

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 184 A method invocation mDb.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 230

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 230 A method invocation onEndTransaction(callerIsSyncAdapter) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/stub/NullController.java

Rule Standard Line number
OBJ10-J CERT 20

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 20 code block public static NullController INSTANCE=new NullController(); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/TabBar.java

Rule Standard Line number
SER05-J CERT 239

SER05-J. Do not serialize instances of inner classes

"An inner class is a nested class that is not explicitly or implicitly declared static". Serialization of inner classes (including local and anonymous classes) is error prone.

In the given program line number 239 code block ' Outer class name 'TabBar' Inner class name 'TabView' Instances name[OnClickListener] trying to serialize instances of inner classes

Non-compliant Solution

In this noncompliant code example, the fields contained within the outer class are serialized when the inner class is serialized:

 
 public class OuterSer implements Serializable {
  private int rank;
  class InnerSer implements Serializable {
    protected String name;
    // ...
  }
}
 

Compliant Solution

The InnerSer class of this compliant solution deliberately fails to implement the Serializable interface:

 
 public class OuterSer implements Serializable {
  private int rank;
  class InnerSer {
    protected String name;
    // ...
  }
}
 

Additional information

Related Guidelines

  • CWE-499, Serializable Class Containing Sensitive Data

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/UI.java

Rule Standard Line number
OBJ10-J CERT 37

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 37 code block public static enum ComboViews; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/Controller.java

Rule Standard Line number
ERR05-J CERT 2076

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2076 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/CrashRecoveryHandler.java

Rule Standard Line number
FIO02-J CERT 95

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 95 code block state.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

ERR05-J CERT 246

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 246 A method invocation p.recycle() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 240

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 240 code block stateFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 240

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 240 code block stateFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 240

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 240 code block stateFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 240

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 240 code block stateFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/DataController.java

Rule Standard Line number
ERR05-J CERT 238

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 238 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 267

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 267 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 286

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 286 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Browser/src/com/android/browser/DownloadTouchIcon.java

Rule Standard Line number
ERR05-J CERT 133

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 133 A method invocation connection.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/alerts/AlarmScheduler.java

Rule Standard Line number
ERR05-J CERT 122

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 122 A method invocation instancesCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 274

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 274 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/alerts/AlertReceiver.java

Rule Standard Line number
ERR05-J CERT 640

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 640 A method invocation eventCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 664

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 664 A method invocation attendeesCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 692

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 692 A method invocation eventCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 719

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 719 A method invocation attendeesCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/alerts/AlertService.java

Rule Standard Line number
ERR05-J CERT 830

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 830 A method invocation alertCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1081

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1081 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/alerts/GlobalDismissManager.java

Rule Standard Line number
ERR05-J CERT 325

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 325 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 437

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 437 A method invocation eventCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 471

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 471 A method invocation calendarCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 514

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 514 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/AllInOneActivity.java

Rule Standard Line number
ERR05-J CERT 208

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 208 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/GoogleCalendarUriIntentFilter.java

Rule Standard Line number
ERR05-J CERT 237

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 237 A method invocation eventCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/month/SimpleDayPickerFragment.java

Rule Standard Line number
OBJ10-J CERT 72

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 72 code block public static int LIST_TOP_OFFSET=-1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/selectcalendars/SelectSyncedCalendarsMultiAccountAdapter.java

Rule Standard Line number
ERR08-J CERT 176

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 176 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/widget/CalendarAppWidgetService.java

Rule Standard Line number
ERR05-J CERT 505

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 505 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/event/AttendeesView.java

Rule Standard Line number
ERR05-J CERT 466

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 466 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/event/EditEventFragment.java

Rule Standard Line number
ERR05-J CERT 302

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 302 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 322

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 322 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 344

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 344 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/event/EditEventHelper.java

Rule Standard Line number
ERR07-J CERT 735

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 735 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 739

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 739 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/event/EventLocationAdapter.java

Rule Standard Line number
ERR05-J CERT 414

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 414 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 444

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 444 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/Event.java

Rule Standard Line number
ERR05-J CERT 283

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 283 A method invocation Debug.stopMethodTracing() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/EventLoader.java

Rule Standard Line number
ERR05-J CERT 113

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 113 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Calendar/src/com/android/calendar/CalendarEventModel.java

Rule Standard Line number
DCL02-J CERT 350

DCL02-J. Do not modify the collection's elements during an enhanced for statement

Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement. Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.

In the given program line number 350 code block contains email trying to modify the collection's elements during an enhanced for statement

Non-compliant Solution

This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:

 
List list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;
 
System.out.println("Processing list...");
for (Integer i: list) {
  if (first) {
    first = false;
    i = new Integer(99);
  }
  System.out.println(" New item: " + i);
  // Process i
}
 
System.out.println("Modified list?");
for (Integer i: list) {
  System.out.println("List item: " + i);
}
 

Compliant Solution

This compliant solution processes the "modified" list but leaves the actual list unchanged:

 
// ...
 
for (final Integer i: list) {
  Integer item = i;
  if (first) {
    first = false;
    item = new Integer(99);
  }
  System.out.println(" New item: " + item);
  // Process item
}
 
// ...
 

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/CameraErrorCallback.java

Rule Standard Line number
ERR07-J CERT 32

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 32 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/CameraHolder.java

Rule Standard Line number
ERR07-J CERT 213

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 213 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 248

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 248 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/CameraManager.java

Rule Standard Line number
ERR07-J CERT 119

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 119 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 167

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 167 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 250

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 250 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/PhotoModule.java

Rule Standard Line number
ERR05-J CERT 1362

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1362 A method invocation Util.closeSilently(outputStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1392

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1392 A method invocation Util.closeSilently(tempStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 1378

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 1378 code block path.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 1765

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 1765 code block path.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 1765

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 1765 code block path.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

DCL00-J CERT 2090

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 2090 have DCL00-J because mActivity.getString(R.string.setting_on_value).equals(hdr) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/EffectsRecorder.java

Rule Standard Line number
ERR07-J CERT 287

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 287 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 319

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 319 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 321

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 321 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 323

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 323 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 334

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 334 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 336

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 336 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 346

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 346 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 348

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 348 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 360

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 360 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 362

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 362 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 380

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 380 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 382

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 382 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 397

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 397 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 399

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 399 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 411

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 411 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 413

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 413 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 429

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 429 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 432

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 432 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 459

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 459 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 461

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 461 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 522

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 522 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 535

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 535 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 544

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 544 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 556

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 556 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 558

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 558 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 569

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 569 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 571

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 571 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 634

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 634 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 698

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 698 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 700

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 700 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 706

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 706 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 709

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 709 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 712

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 712 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 720

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 720 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 891

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 891 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 893

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 893 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 900

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 900 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 955

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 955 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1008

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1008 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1079

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1079 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1168

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1168 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1177

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1177 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1185

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1185 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1193

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1193 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1201

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1201 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1210

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1210 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1219

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1219 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1228

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1228 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1236

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1236 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/ui/OnIndicatorEventListener.java

Rule Standard Line number
OBJ10-J CERT 20

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 20 code block public static int EVENT_ENTER_SECOND_LEVEL_INDICATOR_BAR=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 21

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 21 code block public static int EVENT_LEAVE_SECOND_LEVEL_INDICATOR_BAR=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 22

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 22 code block public static int EVENT_ENTER_ZOOM_CONTROL=2; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 23

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 23 code block public static int EVENT_LEAVE_ZOOM_CONTROL=3; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/Util.java

Rule Standard Line number
ERR07-J CERT 319

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 319 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/VideoModule.java

Rule Standard Line number
ERR05-J CERT 919

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 919 A method invocation Util.showErrorAndFinish(mActivity,R.string.camera_disabled) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 911

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 911 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1254

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1254 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 2102

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 2102 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/MosaicFrameProcessor.java

Rule Standard Line number
ERR07-J CERT 119

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 119 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/MosaicPreviewRenderer.java

Rule Standard Line number
ERR07-J CERT 128

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 128 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 132

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 132 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 142

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 142 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 147

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 147 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 151

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 151 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/OnScreenHint.java

Rule Standard Line number
ERR07-J CERT 82

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 82 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 125

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 125 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 130

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 130 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera/src/com/android/camera/PanoramaModule.java

Rule Standard Line number
ERR07-J CERT 765

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 765 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 807

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 807 A method invocation mPartialWakeLock.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 938

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 938 A method invocation Util.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/data/DataUtils.java

Rule Standard Line number
ERR05-J CERT 45

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 45 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/data/Location.java

Not Available Not Available
Rule Standard Line number
NUM07-J CERT 27
NUM07-J CERT 27

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/OnScreenHint.java

Rule Standard Line number
ERR07-J CERT 82

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 82 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 126

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 126 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 131

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 131 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/settings/CameraSettingsActivity.java

Rule Standard Line number
ERR07-J CERT 259

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 259 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/settings/ResolutionUtil.java

Rule Standard Line number
OBJ10-J CERT 62

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 62 code block public static Size NEXUS_5_LARGE_16_BY_9_SIZE=new Size(3264,1836); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/settings/SettingsUtil.java

Rule Standard Line number
OBJ10-J CERT 134

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 134 code block /** * Video qualities sorted by size. */ public static int[] sVideoQualities=new int[]{CamcorderProfile.QUALITY_2160P,CamcorderProfile.QUALITY_1080P,CamcorderProfile.QUALITY_720P,CamcorderProfile.QUALITY_480P,CamcorderProfile.QUALITY_CIF,CamcorderProfile.QUALITY_QVGA,CamcorderProfile.QUALITY_QCIF}; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 145

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 145 code block public static SparseArray sCachedSelectedPictureSizes=new SparseArray(2); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 147

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 147 code block public static SparseArray sCachedSelectedVideoQualities=new SparseArray(2); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/app/ModuleManager.java

Rule Standard Line number
OBJ10-J CERT 32

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 32 code block public static int MODULE_INDEX_NONE=-1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/app/OrientationManager.java

Rule Standard Line number
OBJ10-J CERT 9

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 9 code block public static enum DeviceNaturalOrientation; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 19

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 19 code block public static enum DeviceOrientation; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/async/MainThread.java

Rule Standard Line number
ERR05-J CERT 74

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 74 A method invocation sIsMainThread.set(false) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/ButtonManager.java

Rule Standard Line number
ERR05-J CERT 988

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 988 A method invocation descriptionIds.recycle() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/captureintent/CaptureIntentSession.java

Rule Standard Line number
ERR07-J CERT 130

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 130 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 136

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 136 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 142

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 142 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 168

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 168 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 173

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 173 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 178

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 178 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 183

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 183 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/captureintent/state/StateSavingPicture.java

Rule Standard Line number
ERR05-J CERT 95

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 95 A method invocation CameraUtil.closeSilently(outputStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/captureintent/stateful/State.java

Rule Standard Line number
OBJ10-J CERT 31

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 31 code block public static Optional NO_CHANGE=Optional.absent(); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/captureintent/stateful/StateMachineImpl.java

Rule Standard Line number
ERR05-J CERT 73

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 73 A method invocation mStateLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 83

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 83 A method invocation mStateLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 97

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 97 A method invocation mStateLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 117

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 117 A method invocation mStateLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/CaptureModule.java

Rule Standard Line number
ERR07-J CERT 1326

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1326 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1329

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1329 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1507

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1507 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 1518

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1518 A method invocation mCameraOpenCloseLock.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/PhotoModule.java

Rule Standard Line number
ERR05-J CERT 1291

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1291 A method invocation CameraUtil.closeSilently(outputStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1326

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1326 A method invocation CameraUtil.closeSilently(tempStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 1309

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 1309 code block path.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

ERR05-J CERT 2244

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2244 A method invocation CameraUtil.closeSilently(outputStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/processing/imagebackend/ImageBackend.java

Rule Standard Line number
ERR07-J CERT 256

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 256 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 436

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 436 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 629

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 629 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 704

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 704 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 740

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 740 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 788

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 788 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 875

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 875 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 895

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 895 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/processing/imagebackend/TaskChainedCompressImageToJpeg.java

Rule Standard Line number
ERR05-J CERT 77

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 77 A method invocation mImageTaskManager.releaseSemaphoreReference(img,mExecutor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/processing/imagebackend/TaskCompressImageToJpeg.java

Rule Standard Line number
ERR05-J CERT 229

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 229 A method invocation mImageTaskManager.releaseSemaphoreReference(img,mExecutor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 314

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 314 A method invocation mImageTaskManager.releaseSemaphoreReference(img,mExecutor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 308

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 308 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 374

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 374 A method invocation mSession.getCollector() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/processing/imagebackend/TaskConvertImageToRGBPreview.java

Rule Standard Line number
ERR05-J CERT 888

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 888 A method invocation mImageTaskManager.releaseSemaphoreReference(img,mExecutor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/processing/imagebackend/TaskJpegEncode.java

Rule Standard Line number
ERR02-J CERT 173

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 173 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/processing/imagebackend/TaskPreviewChainedJpeg.java

Rule Standard Line number
ERR05-J CERT 88

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 88 A method invocation mImageTaskManager.releaseSemaphoreReference(img,mExecutor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/processing/ProcessingService.java

Rule Standard Line number
ERR05-J CERT 164

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 164 A method invocation mSuspendStatusLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 177

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 177 A method invocation mSuspendStatusLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 204

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 204 A method invocation mSuspendStatusLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/SurfaceTextureRenderer.java

Rule Standard Line number
ERR07-J CERT 119

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 119 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 123

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 123 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 133

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 133 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 138

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 138 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 143

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 143 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/tinyplanet/TinyPlanetFragment.java

Rule Standard Line number
ERR05-J CERT 163

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 163 A method invocation mResultLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 341

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 341 A method invocation mResultLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 407

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 407 A method invocation mResultLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/tinyplanet/TinyPlanetPreview.java

Rule Standard Line number
ERR05-J CERT 88

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 88 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/util/ConcurrentSharedRingBuffer.java

Rule Standard Line number
ERR04-J CERT 312

ERR04-J. Do not complete abruptly from a finally block

Never use return, break, continue, or throw statements within a finally block. When program execution enters a try block that has a finally block, the finally block always executes regardless of whether the try block (or any associated catch blocks) executes to normal completion. Statements that cause the finally block to complete abruptly also cause the try block to complete abruptly and consequently suppress any exception thrown from the try or catch blocks.

In the given program line number 312 An abruptly statement return false; is present in finally block

Non-compliant Solution

In this noncompliant code example, the finally block completes abruptly because of a return statement in the block

 
 class TryNC {
  private static boolean doSomeThing() {
    try {
      throw new IllegalStateException();
    } finally {
      System.out.println("Done");
      return true;
    }
  }
}
 

Compliant Solution

This compliant solution removes the return statement from the finally block

 
 class TryNC {
  private static boolean doSomeThing() {
    try {
      throw new IllegalStateException();
    } finally {
      System.out.println("logic done");
     
    }
    //Add return statement here
  }
}

Additional information

Related Guidelines

ERR05-J CERT 316

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 316 A method invocation mUnpinnedElements.put(newKey,toSwap) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR04-J CERT 473

ERR04-J. Do not complete abruptly from a finally block

Never use return, break, continue, or throw statements within a finally block. When program execution enters a try block that has a finally block, the finally block always executes regardless of whether the try block (or any associated catch blocks) executes to normal completion. Statements that cause the finally block to complete abruptly also cause the try block to complete abruptly and consequently suppress any exception thrown from the try or catch blocks.

In the given program line number 473 An abruptly statement return pinnedCandidate; is present in finally block

Non-compliant Solution

In this noncompliant code example, the finally block completes abruptly because of a return statement in the block

 
 class TryNC {
  private static boolean doSomeThing() {
    try {
      throw new IllegalStateException();
    } finally {
      System.out.println("Done");
      return true;
    }
  }
}
 

Compliant Solution

This compliant solution removes the return statement from the finally block

 
 class TryNC {
  private static boolean doSomeThing() {
    try {
      throw new IllegalStateException();
    } finally {
      System.out.println("logic done");
     
    }
    //Add return statement here
  }
}

Additional information

Related Guidelines

ERR05-J CERT 475

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 475 A method invocation release(pinnedCandidate.first) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/util/FileUtil.java

Rule Standard Line number
ERR05-J CERT 69

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 69 A method invocation stream.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/util/JpegUtilNative.java

Rule Standard Line number
ERR07-J CERT 124

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 124 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/util/XmpUtil.java

Rule Standard Line number
ERR02-J CERT 74

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 74 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Camera2/src/com/android/camera/VideoModule.java

Rule Standard Line number
ERR07-J CERT 967

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 967 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1189

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1189 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/CellBroadcastReceiver/src/com/android/cellbroadcastreceiver/CellBroadcastAlertService.java

Rule Standard Line number
ERR02-J CERT 136

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 136 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/CellBroadcastReceiver/src/com/android/cellbroadcastreceiver/CellBroadcastContentProvider.java

Rule Standard Line number
ERR05-J CERT 316

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 316 A method invocation cpc.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/CellBroadcastReceiver/src/com/android/cellbroadcastreceiver/CellBroadcastDatabaseHelper.java

Rule Standard Line number
ERR05-J CERT 148

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 148 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 141

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 141 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/CertInstaller/src/com/android/certinstaller/CertInstaller.java

Rule Standard Line number
ERR05-J CERT 207

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 207 A method invocation keyChainConnection.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/CertInstaller/src/com/android/certinstaller/CertInstallerMain.java

Rule Standard Line number
ERR05-J CERT 148

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 148 A method invocation IoUtils.closeQuietly(in) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/CertInstaller/src/com/android/certinstaller/Util.java

Rule Standard Line number
ERR07-J CERT 66

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 66 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/interactions/CalendarInteractionsLoader.java

Rule Standard Line number
ERR05-J CERT 170

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 170 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/activities/ActionBarAdapter.java

Rule Standard Line number
OBJ10-J CERT 111

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 111 code block public static int FAVORITES=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 112

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 112 code block public static int ALL=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 114

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 114 code block public static int COUNT=2; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 115

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 115 code block public static int DEFAULT=ALL; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/activities/AttachPhotoActivity.java

Rule Standard Line number
ERR05-J CERT 124

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 124 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/activities/ConfirmAddDetailActivity.java

Rule Standard Line number
ERR05-J CERT 428

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 428 A method invocation contactIdCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 575

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 575 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/activities/ShowOrCreateActivity.java

Rule Standard Line number
ERR05-J CERT 176

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 176 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/ContactSaveService.java

Rule Standard Line number
ERR07-J CERT 292

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 292 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 427

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 427 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 875

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 875 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1249

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1249 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/datepicker/DatePicker.java

Rule Standard Line number
OBJ10-J CERT 54

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 54 code block /** * Magic year that represents "no year" */ public static int NO_YEAR=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/datepicker/DatePickerDialog.java

Rule Standard Line number
OBJ10-J CERT 46

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 46 code block /** * Magic year that represents "no year" */ public static int NO_YEAR=DatePicker.NO_YEAR; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/detail/PhotoSelectionHandler.java

Rule Standard Line number
ERR05-J CERT 299

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 299 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/editor/AggregationSuggestionEngine.java

Rule Standard Line number
ERR05-J CERT 333

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 333 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/editor/KindSectionView.java

Rule Standard Line number
ERR07-J CERT 245

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 245 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/group/SuggestedMemberListAdapter.java

Rule Standard Line number
ERR05-J CERT 232

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 232 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 293

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 293 A method invocation memberDataCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/list/ContactBrowseListFragment.java

Rule Standard Line number
ERR05-J CERT 134

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 134 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/list/ProviderStatusWatcher.java

Rule Standard Line number
ERR05-J CERT 234

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 234 A method invocation mSignal.notifyAll() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 228

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 228 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/list/JoinContactLoader.java

Rule Standard Line number
ERR05-J CERT 100

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 100 A method invocation cursorToClose.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/quickcontact/QuickContactActivity.java

Rule Standard Line number
ERR05-J CERT 1921

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1921 A method invocation bitmap.recycle() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Contacts/src/com/android/contacts/SplitAggregateView.java

Rule Standard Line number
ERR05-J CERT 186

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 186 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/activity/RequestPermissionsActivityBase.java

Rule Standard Line number
ERR05-J CERT 159

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 159 A method invocation Trace.endSection() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/ContactPhotoManager.java

Rule Standard Line number
OBJ10-J CERT 317

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 317 code block /** * Used to indicate that a drawable that represents a contact without any contact details * should be returned. */ public static DefaultImageRequest EMPTY_DEFAULT_IMAGE_REQUEST=new DefaultImageRequest(); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 323

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 323 code block /** * Used to indicate that a drawable that represents a business without a business photo * should be returned. */ public static DefaultImageRequest EMPTY_DEFAULT_BUSINESS_IMAGE_REQUEST=new DefaultImageRequest(null,null,TYPE_BUSINESS,false); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 330

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 330 code block /** * Used to indicate that a circular drawable that represents a contact without any contact * details should be returned. */ public static DefaultImageRequest EMPTY_CIRCULAR_DEFAULT_IMAGE_REQUEST=new DefaultImageRequest(null,null,true); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 337

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 337 code block /** * Used to indicate that a circular drawable that represents a business without a business * photo should be returned. */ public static DefaultImageRequest EMPTY_CIRCULAR_BUSINESS_IMAGE_REQUEST=new DefaultImageRequest(null,null,TYPE_BUSINESS,true); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 431

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 431 code block public static DefaultImageProvider DEFAULT_AVATAR=new LetterTileDefaultImageProvider(); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

SER05-J CERT 1278

SER05-J. Do not serialize instances of inner classes

"An inner class is a nested class that is not explicitly or implicitly declared static". Serialization of inner classes (including local and anonymous classes) is error prone.

In the given program line number 1278 code block ' Outer class name 'ContactPhotoManagerImpl' Inner class name 'LoaderThread' Instances name[Callback] trying to serialize instances of inner classes

Non-compliant Solution

In this noncompliant code example, the fields contained within the outer class are serialized when the inner class is serialized:

 
 public class OuterSer implements Serializable {
  private int rank;
  class InnerSer implements Serializable {
    protected String name;
    // ...
  }
}
 

Compliant Solution

The InnerSer class of this compliant solution deliberately fails to implement the Serializable interface:

 
 public class OuterSer implements Serializable {
  private int rank;
  class InnerSer {
    protected String name;
    // ...
  }
}
 

Additional information

Related Guidelines

  • CWE-499, Serializable Class Containing Sensitive Data
ERR05-J CERT 1453

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1453 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1515

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1515 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1536

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1536 A method invocation profileCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/ContactsUtils.java

Rule Standard Line number
ERR05-J CERT 150

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 150 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/interactions/ImportExportDialogFragment.java

Rule Standard Line number
ERR05-J CERT 232

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 232 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/list/ContactEntryListFragment.java

Rule Standard Line number
ERR07-J CERT 738

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 738 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/list/ProfileAndContactsLoader.java

Rule Standard Line number
ERR05-J CERT 101

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 101 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/list/ShortcutIntentBuilder.java

Rule Standard Line number
ERR05-J CERT 183

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 183 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 206

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 206 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 242

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 242 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/list/CustomContactListFilterActivity.java

Rule Standard Line number
ERR05-J CERT 169

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 169 A method invocation iterator.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 285

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 285 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/list/DirectoryListLoader.java

Rule Standard Line number
ERR07-J CERT 144

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 144 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 178

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 178 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/model/account/AccountTypeWithDataSet.java

Rule Standard Line number
ERR05-J CERT 76

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 76 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/model/account/AccountWithDataSet.java

Rule Standard Line number
ERR05-J CERT 136

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 136 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/model/account/ExternalAccountType.java

Rule Standard Line number
ERR05-J CERT 161

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 161 A method invocation parser.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/model/ContactLoader.java

Rule Standard Line number
ERR05-J CERT 515

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 515 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 553

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 553 A method invocation fd.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 774

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 774 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/model/RawContactDeltaList.java

Rule Standard Line number
ERR05-J CERT 67

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 67 A method invocation iterator.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/model/RawContactModifier.java

Rule Standard Line number
ERR05-J CERT 648

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 648 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/util/NameConverter.java

Rule Standard Line number
ERR05-J CERT 103

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 103 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 136

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 136 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/util/AccountSelectionUtil.java

Rule Standard Line number
OBJ10-J CERT 48

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 48 code block public static boolean mVCardShare=false; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 50

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 50 code block public static Uri mPath; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/util/ContactListViewUtils.java

Rule Standard Line number
ERR07-J CERT 58

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 58 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/util/LocalizedNameResolver.java

Rule Standard Line number
ERR05-J CERT 135

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 135 A method invocation typedArray.recycle() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/vcard/CancelActivity.java

Rule Standard Line number
ERR05-J CERT 123

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 123 A method invocation unbindService(this) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/vcard/ExportProcessor.java

Rule Standard Line number
ERR05-J CERT 216

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 216 A method invocation mService.handleFinishExportNotification(mJobId,successful) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/vcard/ExportVCardActivity.java

Rule Standard Line number
ERR05-J CERT 215

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 215 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ContactsCommon/src/com/android/contacts/common/vcard/ImportVCardActivity.java

Rule Standard Line number
ERR05-J CERT 333

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 333 A method invocation finish() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 244

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 244 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 287

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 287 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/DeskClock/src/com/android/deskclock/AlarmInitReceiver.java

Rule Standard Line number
ERR05-J CERT 85

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 85 A method invocation LogUtils.v("AlarmInitReceiver finished") is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/DeskClock/src/com/android/deskclock/HandleApiCalls.java

Rule Standard Line number
ERR05-J CERT 83

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 83 A method invocation finish() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/DeskClock/src/com/android/deskclock/HandleDeskClockApiCalls.java

Rule Standard Line number
ERR05-J CERT 115

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 115 A method invocation finish() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/DeskClock/src/com/android/deskclock/provider/Alarm.java

Rule Standard Line number
ERR05-J CERT 148

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 148 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 182

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 182 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/DeskClock/src/com/android/deskclock/provider/AlarmInstance.java

Rule Standard Line number
ERR05-J CERT 155

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 155 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/DeskClock/src/com/android/deskclock/provider/City.java

Rule Standard Line number
ERR05-J CERT 93

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 93 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 127

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 127 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/DeskClock/src/com/android/deskclock/provider/ClockDatabaseHelper.java

Rule Standard Line number
ERR05-J CERT 226

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 226 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/DeskClock/src/com/android/deskclock/Utils.java

Rule Standard Line number
ERR05-J CERT 731

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 731 A method invocation a.recycle() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/DeskClock/src/com/android/deskclock/widget/TextTime.java

Rule Standard Line number
ERR05-J CERT 73

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 73 A method invocation styledAttributes.recycle() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/calllog/ContactInfo.java

Rule Standard Line number
OBJ10-J CERT 49

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 49 code block public static ContactInfo EMPTY=new ContactInfo(); trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/calllog/CallLogAsyncTaskUtil.java

Rule Standard Line number
ERR05-J CERT 192

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 192 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/calllog/CallLogQueryHandler.java

Rule Standard Line number
ERR05-J CERT 251

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 251 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/calllog/ContactInfoHelper.java

Rule Standard Line number
ERR05-J CERT 194

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 194 A method invocation phonesCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/calllog/DefaultVoicemailNotifier.java

Rule Standard Line number
ERR05-J CERT 309

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 309 A method invocation MoreCloseables.closeQuietly(cursor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 382

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 382 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/database/DialerDatabaseHelper.java

Rule Standard Line number
ERR05-J CERT 459

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 459 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 551

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 551 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 612

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 612 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 707

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 707 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 746

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 746 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 827

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 827 A method invocation updatedContactCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 852

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 852 A method invocation nameCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1013

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1013 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/dialpad/DialpadFragment.java

Rule Standard Line number
ERR05-J CERT 468

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 468 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/interactions/PhoneNumberInteraction.java

Rule Standard Line number
ERR05-J CERT 434

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 434 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/interactions/UndemoteOutgoingCallReceiver.java

Rule Standard Line number
ERR05-J CERT 106

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 106 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/SpecialCharSequenceMgr.java

Rule Standard Line number
ERR05-J CERT 486

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 486 A method invocation MoreCloseables.closeQuietly(c) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/voicemail/VoicemailPlaybackPresenter.java

Rule Standard Line number
ERR05-J CERT 381

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 381 A method invocation MoreCloseables.closeQuietly(cursor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Dialer/src/com/android/dialer/voicemail/VoicemailStatusHelperImpl.java

Rule Standard Line number
OBJ10-J CERT 59

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 59 code block /** * Possible user actions. */ public static enum Action; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/provider/Account.java

Rule Standard Line number
OBJ10-J CERT 115

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 115 code block public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 116

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 116 code block public static Uri RESET_NEW_MESSAGE_COUNT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 117

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 117 code block public static Uri NOTIFIER_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 236

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 236 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 258

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 258 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 497

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 497 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 617

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 617 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/provider/Credential.java

Rule Standard Line number
OBJ10-J CERT 21

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 21 code block public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/provider/EmailContent.java

Rule Standard Line number
OBJ10-J CERT 142

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 142 code block public static String EMAIL_PACKAGE_NAME; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 143

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 143 code block public static String AUTHORITY; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 147

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 147 code block public static String NOTIFIER_AUTHORITY; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 148

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 148 code block public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 155

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 155 code block public static Uri CONTENT_NOTIFIER_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 156

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 156 code block public static Uri PICK_TRASH_FOLDER_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 157

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 157 code block public static Uri PICK_SENT_FOLDER_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 158

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 158 code block public static Uri MAILBOX_NOTIFICATION_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 159

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 159 code block public static Uri MAILBOX_MOST_RECENT_MESSAGE_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 160

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 160 code block public static Uri ACCOUNT_CHECK_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 162

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 162 code block /** * String for both the EmailProvider call, and the key for the value in the response. * TODO: Eventually this ought to be a device property, not defined by the app. */ public static String DEVICE_FRIENDLY_NAME="deviceFriendlyName"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 169

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 169 code block public static String PROVIDER_PERMISSION; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 258

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 258 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR02-J CERT 369

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 369 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 371

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 371 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

OBJ10-J CERT 474

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 474 code block public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 535

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 535 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 610

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 610 A method invocation bodyInput.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
OBJ10-J CERT 714

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 714 code block public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 715

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 715 code block public static Uri CONTENT_URI_LIMIT_1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 716

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 716 code block public static Uri SYNCED_CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 717

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 717 code block public static Uri SELECTED_MESSAGE_CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 718

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 718 code block public static Uri DELETED_CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 719

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 719 code block public static Uri UPDATED_CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 720

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 720 code block public static Uri NOTIFIER_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 1337

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 1337 code block public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 1339

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 1339 code block public static Uri MESSAGE_ID_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 1340

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 1340 code block public static String ATTACHMENT_PROVIDER_URI_PREFIX; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 1341

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 1341 code block public static String ATTACHMENT_PROVIDER_AUTHORITY; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 1342

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 1342 code block public static boolean sUsingLegacyPrefix; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 1504

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1504 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/provider/HostAuth.java

Rule Standard Line number
OBJ10-J CERT 40

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 40 code block public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/provider/Mailbox.java

Rule Standard Line number
OBJ10-J CERT 79

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 79 code block public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 80

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 80 code block public static Uri MESSAGE_COUNT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 532

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 532 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 990

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 990 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/provider/MailboxUtilities.java

Rule Standard Line number
ERR05-J CERT 88

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 88 A method invocation childCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 121

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 121 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 156

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 156 A method invocation noParentKeyMailboxCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 276

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 276 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/provider/MessageMove.java

Rule Standard Line number
OBJ10-J CERT 28

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 28 code block /** * The URI for dealing with message move data. */ public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 159

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 159 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 241

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 241 A method invocation moveCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 255

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 255 A method invocation messageCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/provider/MessageStateChange.java

Rule Standard Line number
OBJ10-J CERT 27

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 27 code block /** * The URI for dealing with message move data. */ public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 164

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 164 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/provider/Policy.java

Rule Standard Line number
OBJ10-J CERT 44

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 44 code block public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 220

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 220 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/provider/QuickResponse.java

Rule Standard Line number
OBJ10-J CERT 31

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 31 code block public static Uri CONTENT_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 32

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 32 code block public static Uri ACCOUNT_ID_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/service/ServiceProxy.java

Rule Standard Line number
ERR05-J CERT 132

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 132 A method invocation LogUtils.e(mTag,e,"RuntimeException when trying to unbind from service") is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/utility/AttachmentUtilities.java

Rule Standard Line number
ERR05-J CERT 287

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 287 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 314

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 314 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 311

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 311 code block attachmentFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

ERR05-J CERT 342

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 342 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 338

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 338 code block cachedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 338

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 338 code block cachedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

ERR05-J CERT 364

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 364 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/utility/SSLUtils.java

Rule Standard Line number
ERR05-J CERT 86

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 86 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/emailcommon/src/com/android/emailcommon/utility/Utility.java

Rule Standard Line number
ERR05-J CERT 208

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 208 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 204

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 204 A method invocation c2.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 575

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 575 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 763

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 763 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/DebugUtils.java

Rule Standard Line number
OBJ10-J CERT 13

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 13 code block public static boolean DEBUG; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 14

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 14 code block public static boolean DEBUG_EXCHANGE; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 15

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 15 code block public static boolean DEBUG_FILE; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/EmailConnectivityManager.java

Rule Standard Line number
ERR05-J CERT 212

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 212 A method invocation mWakeLock.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/LegacyConversions.java

Rule Standard Line number
ERR05-J CERT 298

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 298 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 345

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 345 A method invocation out.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 459

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 459 A method invocation attachments.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/mail/store/imap/ImapElement.java

Rule Standard Line number
ERR07-J CERT 97

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 97 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/mail/store/imap/ImapList.java

Rule Standard Line number
ERR07-J CERT 35

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 35 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 43

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 43 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/mail/store/imap/ImapResponseParser.java

Rule Standard Line number
ERR05-J CERT 323

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 323 A method invocation responseToDestroy.destroy() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/mail/store/ImapConnection.java

Rule Standard Line number
ERR05-J CERT 195

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 195 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/mail/store/ImapFolder.java

Rule Standard Line number
ERR05-J CERT 115

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 115 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 139

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 139 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 217

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 217 A method invocation mStore.poolConnection(connection) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 258

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 258 A method invocation mStore.poolConnection(connection) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 343

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 343 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 335

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 335 A method invocation newFolder.close(false) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 372

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 372 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 436

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 436 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
DCL00-J CERT 447

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 447 have DCL00-J because uids[i].equals(uid) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

ERR05-J CERT 504

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 504 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 786

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 786 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 824

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 824 A method invocation out.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1155

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1155 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1111

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1111 A method invocation mConnection.mTransport.setSoTimeout(socketTimeout) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1167

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1167 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1204

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1204 A method invocation destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/mail/store/ImapStore.java

Rule Standard Line number
ERR05-J CERT 481

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 481 A method invocation poolConnection(connection) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 501

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 501 A method invocation connection.destroyResponses() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/mail/store/Pop3Store.java

Rule Standard Line number
ERR05-J CERT 137

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 137 A method invocation folder.close(false) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/mail/transport/MailTransport.java

Rule Standard Line number
MSC00-J CERT 118

MSC00-J. Use SSLSocket rather than Socket for secure data exchange

Programs must use the javax.net.ssl.SSLSocket class rather than the java.net.Socket class when transferring sensitive data over insecure communication channels. The class SSLSocket provides security protocols such as Secure Sockets Layer/Transport Layer Security (SSL/TLS) to ensure that the channel is not vulnerable to eavesdropping and malicious tampering.

In the given program line number 118 code block Use SSLSocket rather than Socket use SSLSocket rather than Socket for secure data exchange

Non-compliant Solution

This noncompliant code example shows the use of regular sockets for a server application that fails to protect sensitive information in transit. The insecure code for the corresponding client application follows the server's code.

 
class EchoServer {
  public static void main(String[] args) throws IOException {
    ServerSocket serverSocket = null;
    try {
      serverSocket = new ServerSocket(9999);
      Socket socket = serverSocket.accept();
      PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
      BufferedReader in = new BufferedReader(
          new InputStreamReader(socket.getInputStream()));
      String inputLine;
      while ((inputLine = in.readLine()) != null) {
        System.out.println(inputLine);
        out.println(inputLine);
      }
    } finally {
      if (serverSocket != null) {
        try {
          serverSocket.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}
 
 

Compliant Solution

This compliant solution uses SSLSocket to protect packets using the SSL/TLS security protocols:

 
class EchoServer {
  public static void main(String[] args) throws IOException {
    SSLServerSocket sslServerSocket = null;
    try {
      SSLServerSocketFactory sslServerSocketFactory =
          (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
      sslServerSocket = (SSLServerSocket) sslServerSocketFactory.
                        createServerSocket(9999);
      SSLSocket sslSocket = (SSLSocket) sslServerSocket.accept();
      PrintWriter out = new PrintWriter(sslSocket.getOutputStream(),true);
      BufferedReader in = new BufferedReader(
          new InputStreamReader(sslSocket.getInputStream()));
      String inputLine;
      while ((inputLine = in.readLine()) != null) {
        System.out.println(inputLine);
        out.println(inputLine);
      }
    } finally {
      if (sslServerSocket != null) {
        try {
          sslServerSocket.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/provider/AccountReconciler.java

Rule Standard Line number
ERR05-J CERT 94

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 94 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
DCL00-J CERT 127

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 127 have DCL00-J because account.type.equalsIgnoreCase(type) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/provider/AttachmentProvider.java

Rule Standard Line number
ERR05-J CERT 128

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 128 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 123

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 123 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 225

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 225 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 191

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 191 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 302

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 302 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 279

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 279 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/provider/ContentCache.java

Rule Standard Line number
ERR05-J CERT 506

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 506 A method invocation mTokenList.remove(token) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/provider/DBHelper.java

Rule Standard Line number
ERR05-J CERT 756

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 756 A method invocation w.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 771

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 771 A method invocation w.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 786

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 786 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 1508

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1508 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
DCL00-J CERT 1589

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 1589 have DCL00-J because TextUtils.equals(account.type,type) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

ERR05-J CERT 1657

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1657 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1653

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1653 A method invocation hostAuthCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1738

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1738 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1734

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1734 A method invocation hostAuthCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1780

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1780 A method invocation messageCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1806

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1806 A method invocation messageCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/provider/EmailMessageCursor.java

Rule Standard Line number
ERR05-J CERT 77

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 77 A method invocation in.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 93

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 93 A method invocation in.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/provider/EmailProvider.java

Rule Standard Line number
OBJ10-J CERT 160

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 160 code block public static String EMAIL_APP_MIME_TYPE; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 380

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 380 code block public static Uri INTEGRITY_CHECK_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 382

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 382 code block public static Uri ACCOUNT_BACKUP_URI; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 624

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 624 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 614

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 614 A method invocation boxCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 798

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 798 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 674

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 674 A method invocation findCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 787

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 787 A method invocation orphans.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 865

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 865 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1536

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1536 A method invocation LogUtils.w(TAG,"Query returning null for uri: %s selection: %s",uri,selection) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1516

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1516 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR02-J CERT 1528

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 1528 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR05-J CERT 1592

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1592 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1672

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1672 A method invocation fromDatabase.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1666

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1666 A method invocation toDatabase.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1660

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1660 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1702

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1702 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1873

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1873 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1974

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1974 A method invocation ic.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1992

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1992 A method invocation findCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2021

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2021 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2190

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2190 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2374

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2374 A method invocation w.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2426

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2426 A method invocation Binder.restoreCallingIdentity(binderToken) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2548

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2548 A method invocation context.getContentResolver() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3976

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3976 A method invocation accountIdCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 3969

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 3969 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 4232

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 4232 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 4260

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 4260 A method invocation fc.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 4483

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 4483 A method invocation inputCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 4759

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 4759 A method invocation closeThis.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 5455

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 5455 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 5564

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 5564 A method invocation ac.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 6175

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 6175 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 6222

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 6222 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 6340

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 6340 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/provider/FolderPickerDialog.java

Rule Standard Line number
ERR05-J CERT 69

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 69 A method invocation foldersCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/provider/Utilities.java

Rule Standard Line number
ERR05-J CERT 86

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 86 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/provider/WidgetProvider.java

Rule Standard Line number
ERR05-J CERT 80

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 80 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 165

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 165 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/SecurityPolicy.java

Rule Standard Line number
ERR05-J CERT 176

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 176 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 732

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 732 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 831

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 831 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/service/ImapService.java

Rule Standard Line number
ERR05-J CERT 188

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 188 A method invocation remoteStore.closeConnections() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 421

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 421 A method invocation localOldestCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 580

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 580 A method invocation localUidCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 806

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 806 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 860

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 860 A method invocation deletes.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 937

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 937 A method invocation mailboxes.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 924

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 924 A method invocation remoteStore.closeConnections() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1019

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1019 A method invocation updates.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/service/AttachmentService.java

Rule Standard Line number
ERR05-J CERT 684

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 684 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR02-J CERT 682

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 682 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR05-J CERT 968

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 968 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/service/EmailBroadcastProcessorService.java

Rule Standard Line number
ERR05-J CERT 229

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 229 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 363

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 363 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/service/EmailServiceStub.java

Rule Standard Line number
ERR05-J CERT 246

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 246 A method invocation remoteFolder.close(false) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 376

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 376 A method invocation requestSync(inboxId,true,0) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 527

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 527 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/service/EmailServiceUtils.java

Rule Standard Line number
ERR05-J CERT 486

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 486 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 482

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 482 A method invocation LogUtils.w(LogUtils.TAG,"[Incomplete flag cleared]") is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 400

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 400 A method invocation client.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 412

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 412 A method invocation client.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 458

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 458 A method invocation client.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/service/Pop3Service.java

Rule Standard Line number
ERR05-J CERT 260

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 260 A method invocation localUidCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 302

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 302 A method invocation updates.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 442

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 442 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/provider_src/com/android/email/service/PopImapSyncAdapterService.java

Rule Standard Line number
ERR05-J CERT 187

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 187 A method invocation resolver.update(mailboxUri,values,null,null) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 269

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 269 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 225

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 225 A method invocation updatesCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR02-J CERT 266

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 266 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/src/com/android/email/activity/ContactStatusLoader.java

Rule Standard Line number
ERR05-J CERT 121

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 121 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/src/com/android/email/activity/EventViewer.java

Rule Standard Line number
ERR05-J CERT 59

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 59 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/src/com/android/email/activity/setup/DebugFragment.java

Rule Standard Line number
ERR05-J CERT 129

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 129 A method invocation webview.destroy() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/src/com/android/email/EmailNotificationController.java

Rule Standard Line number
ERR05-J CERT 275

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 275 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 336

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 336 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 356

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 356 A method invocation folderCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 564

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 564 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 657

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 657 A method invocation mailboxCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 688

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 688 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 716

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 716 A method invocation folderCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 794

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 794 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/src/com/android/email/preferences/EmailPreferenceMigrator.java

Rule Standard Line number
ERR05-J CERT 63

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 63 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 119

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 119 A method invocation ecAccountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 146

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 146 A method invocation folderCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Email/src/com/android/email2/ui/MailActivityEmail.java

Rule Standard Line number
ERR05-J CERT 117

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 117 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 141

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 141 A method invocation folderCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ExactCalculator/src/com/android/calculator2/Evaluator.java

Rule Standard Line number
MSC02-J CERT 1006

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 1006 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/adapter/AbstractSyncAdapter.java

Rule Standard Line number
ERR07-J CERT 273

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 273 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/adapter/CalendarSyncParser.java

Rule Standard Line number
ERR05-J CERT 205

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 205 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 377

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 377 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1102

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1102 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1210

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1210 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/adapter/ContactsSyncParser.java

Rule Standard Line number
ERR05-J CERT 443

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 443 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 494

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 494 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 583

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 583 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/adapter/EmailSyncParser.java

Rule Standard Line number
ERR05-J CERT 585

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 585 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 631

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 631 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 833

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 833 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/adapter/FolderSyncParser.java

Rule Standard Line number
ERR05-J CERT 308

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 308 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 370

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 370 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 393

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 393 A method invocation mSyncOptionsMap.clear() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 559

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 559 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 674

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 674 A method invocation parentCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 696

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 696 A method invocation childCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 763

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 763 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/eas/EasSearch.java

Rule Standard Line number
ERR05-J CERT 157

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 157 A method invocation is.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/eas/EasFullSyncOperation.java

Rule Standard Line number
ERR05-J CERT 204

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 204 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 269

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 269 A method invocation mContext.getContentResolver() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 331

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 331 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/eas/EasLoadAttachment.java

Rule Standard Line number
ERR05-J CERT 351

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 351 A method invocation tmpFile.delete() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 348

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 348 A method invocation close(os) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 345

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 345 A method invocation close(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 351

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 351 code block tmpFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/eas/EasOperation.java

Rule Standard Line number
ERR05-J CERT 266

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 266 A method invocation onRequestComplete() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 281

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 281 A method invocation onRequestMade() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 396

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 396 A method invocation response.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/eas/EasPing.java

Rule Standard Line number
ERR05-J CERT 166

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 166 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 376

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 376 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/eas/EasSearchGal.java

Rule Standard Line number
ERR05-J CERT 77

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 77 A method invocation is.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/eas/EasSync.java

Rule Standard Line number
ERR05-J CERT 174

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 174 A method invocation mailboxCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/eas/EasSyncCalendar.java

Rule Standard Line number
ERR05-J CERT 185

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 185 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 173

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 173 A method invocation c1.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 285

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 285 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1037

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1037 A method invocation eventIterator.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/eas/EasSyncContacts.java

Rule Standard Line number
ERR05-J CERT 318

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 318 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1008

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1008 A method invocation ei.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 967

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 967 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 994

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 994 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1055

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1055 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/eas/EasSyncMail.java

Rule Standard Line number
ERR05-J CERT 137

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 137 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/Eas.java

Rule Standard Line number
OBJ10-J CERT 38

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 38 code block public static boolean DEBUG=false; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 41

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 41 code block public static boolean USER_LOG=false; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/provider/ExchangeDirectoryProvider.java

Rule Standard Line number
ERR05-J CERT 352

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 352 A method invocation Binder.restoreCallingIdentity(callingId) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/service/CalendarSyncAdapterService.java

Rule Standard Line number
ERR05-J CERT 108

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 108 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/service/ContactsSyncAdapterService.java

Rule Standard Line number
ERR05-J CERT 157

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 157 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/service/EasService.java

Rule Standard Line number
ERR05-J CERT 314

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 314 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 406

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 406 A method invocation operation.getAccount() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 462

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 462 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/service/PingSyncSynchronizer.java

Rule Standard Line number
ERR05-J CERT 372

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 372 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 390

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 390 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 407

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 407 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 419

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 419 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 432

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 432 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 448

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 448 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 462

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 462 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/utility/CalendarUtilities.java

Rule Standard Line number
ERR05-J CERT 2070

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2070 A method invocation eventIterator.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Exchange/src/com/android/exchange/utility/FileLogger.java

Rule Standard Line number
OBJ10-J CERT 29

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 29 code block public static String LOG_FILE_NAME=Environment.getExternalStorageDirectory() + "/emaillog.txt"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/FMRadio/src/com/android/fmradio/dialogs/FmFavoriteEditDialog.java

Rule Standard Line number
ERR02-J CERT 78

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 78 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/FMRadio/src/com/android/fmradio/dialogs/FmSaveDialog.java

Rule Standard Line number
ERR02-J CERT 95

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 95 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

FIO02-J CERT 244

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 244 code block needToDelete.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 244

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 244 code block needToDelete.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 244

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 244 code block needToDelete.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/FMRadio/src/com/android/fmradio/FmFavoriteActivity.java

Rule Standard Line number
ERR02-J CERT 137

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 137 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/FMRadio/src/com/android/fmradio/FmMainActivity.java

Rule Standard Line number
ERR02-J CERT 493

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 493 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 495

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 495 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 497

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 497 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR05-J CERT 626

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 626 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/FMRadio/src/com/android/fmradio/FmRecordActivity.java

Rule Standard Line number
ERR05-J CERT 160

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 160 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/FMRadio/src/com/android/fmradio/FmRecorder.java

Rule Standard Line number
ERR02-J CERT 143

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 143 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR05-J CERT 442

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 442 A method invocation playlistCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 492

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 492 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 516

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 516 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 534

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 534 A method invocation mRecorder.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/FMRadio/src/com/android/fmradio/FmService.java

Rule Standard Line number
OBJ10-J CERT 160

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 160 code block public static int POWER_UP=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 161

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 161 code block public static int DURING_POWER_UP=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 162

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 162 code block public static int POWER_DOWN=2; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 523

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 523 A method invocation mAudioTrack.stop() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR02-J CERT 1592

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 1592 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR05-J CERT 1757

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1757 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2296

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2296 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/FMRadio/src/com/android/fmradio/FmStation.java

Rule Standard Line number
ERR05-J CERT 199

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 199 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 259

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 259 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 288

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 288 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 349

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 349 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/MovieViewControl.java

Rule Standard Line number
ERR05-J CERT 169

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 169 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/BitmapManager.java

Rule Standard Line number
ERR05-J CERT 162

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 162 A method invocation status.notifyAll() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/CropImage.java

Rule Standard Line number
ERR07-J CERT 205

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 205 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 334

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 334 A method invocation Util.closeSilently(outputStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/gallery/BaseImage.java

Rule Standard Line number
ERR05-J CERT 154

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 154 A method invocation Util.closeSilently(input) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/gallery/ImageList.java

Rule Standard Line number
ERR05-J CERT 54

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 54 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/gallery/UriImage.java

Rule Standard Line number
ERR05-J CERT 134

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 134 A method invocation Util.closeSilently(input) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/gallery/VideoList.java

Rule Standard Line number
ERR05-J CERT 98

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 98 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/PhotoAppWidgetProvider.java

Rule Standard Line number
ERR05-J CERT 189

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 189 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/Util.java

Rule Standard Line number
ERR05-J CERT 289

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 289 A method invocation closeSilently(input) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 329

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 329 A method invocation closeSilently(pfd) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 390

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 390 A method invocation mHandler.post(mCleanupRunner) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/ViewImage.java

Rule Standard Line number
MSC02-J CERT 79

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 79 code block new Random(System.currentTimeMillis()) trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

ERR05-J CERT 1184

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1184 A method invocation center(true,true) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/ImageManager.java

Rule Standard Line number
OBJ10-J CERT 123

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 123 code block public static enum DataLocation; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 226

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 226 A method invocation Util.closeSilently(outputStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 453

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 453 code block f.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 453

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 453 code block f.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 453

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 453 code block f.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 453

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 453 code block f.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 453

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 453 code block f.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 458

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 458 code block f.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 458

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 458 code block f.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 458

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 458 code block f.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 458

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 458 code block f.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 458

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 458 code block f.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery/src/com/android/camera/MenuHelper.java

Rule Standard Line number
ERR05-J CERT 136

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 136 A method invocation closeSilently(data) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/common/AsyncTaskUtil.java

Rule Standard Line number
ERR07-J CERT 40

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 40 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 42

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 42 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 44

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 44 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 56

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 56 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 58

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 58 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/common/BlobCache.java

Rule Standard Line number
ERR07-J CERT 364

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 364 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 537

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 537 A method invocation file.seek(oldPosition) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/common/EntrySchema.java

Rule Standard Line number
ERR07-J CERT 141

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 141 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 188

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 188 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 225

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 225 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 242

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 242 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 259

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 259 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/common/FileCache.java

Rule Standard Line number
ERR05-J CERT 178

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 178 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 199

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 199 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 209

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 209 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 245

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 245 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/common/Fingerprint.java

Rule Standard Line number
ERR05-J CERT 95

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 95 A method invocation in.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/common/HttpClientFactory.java

Rule Standard Line number
ERR07-J CERT 77

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 77 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 79

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 79 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 81

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 81 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 83

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 83 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 98

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 98 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 100

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 100 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 102

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 102 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/exif/ExifInterface.java

Rule Standard Line number
ERR05-J CERT 1049

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1049 A method invocation closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1115

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1115 A method invocation is.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/exif/ExifModifier.java

Rule Standard Line number
ERR05-J CERT 62

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 62 A method invocation ExifInterface.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 136

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 136 A method invocation ExifInterface.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/exif/ExifTag.java

Rule Standard Line number
EXP02-J CERT 992

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 992 code block mValue.equals(tag.mValue) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/jpegstream/JPEGInputStream.java

Rule Standard Line number
ERR05-J CERT 117

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 117 A method invocation cleanup() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/gallerycommon/src/com/android/gallery3d/jpegstream/JPEGOutputStream.java

Rule Standard Line number
ERR05-J CERT 107

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 107 A method invocation cleanup() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/anim/StateTransitionAnimation.java

Rule Standard Line number
OBJ10-J CERT 92

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 92 code block public static enum Transition; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/AbstractGalleryActivity.java

Rule Standard Line number
ERR05-J CERT 91

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 91 A method invocation mGLRootView.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 211

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 211 A method invocation mGLRootView.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 227

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 227 A method invocation mGLRootView.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 240

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 240 A method invocation mGLRootView.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 252

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 252 A method invocation mGLRootView.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 264

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 264 A method invocation root.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 282

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 282 A method invocation root.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 346

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 346 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/AlbumDataLoader.java

Rule Standard Line number
ERR07-J CERT 231

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 231 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/AlbumPage.java

Rule Standard Line number
ERR05-J CERT 702

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 702 A method invocation root.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/AlbumSetDataLoader.java

Rule Standard Line number
ERR07-J CERT 322

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 322 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/AlbumSetPage.java

Rule Standard Line number
ERR05-J CERT 720

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 720 A method invocation root.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/SlideshowPage.java

Rule Standard Line number
MSC02-J CERT 242

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 242 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/TrimVideo.java

Rule Standard Line number
ERR02-J CERT 247

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 247 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/VideoUtils.java

Rule Standard Line number
ERR05-J CERT 225

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 225 A method invocation muxer.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 255

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 255 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/GalleryActionBar.java

Rule Standard Line number
ERR05-J CERT 306

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 306 A method invocation mActivity.getGLRoot() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 386

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 386 A method invocation mActivity.getGLRoot() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/GalleryAppImpl.java

Rule Standard Line number
ERR07-J CERT 98

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 98 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/ManageCachePage.java

Rule Standard Line number
ERR05-J CERT 343

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 343 A method invocation root.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/MovieActivity.java

Rule Standard Line number
ERR05-J CERT 159

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 159 A method invocation Utils.closeSilently(cursor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/app/PhotoDataAdapter.java

Rule Standard Line number
ERR07-J CERT 921

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 921 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/BucketHelper.java

Rule Standard Line number
ERR05-J CERT 119

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 119 A method invocation Utils.closeSilently(cursor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 177

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 177 A method invocation Utils.closeSilently(cursor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 195

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 195 A method invocation Utils.closeSilently(cursor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/BytesBufferPool.java

Rule Standard Line number
ERR05-J CERT 59

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 59 A method invocation fis.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/ClusterSource.java

Rule Standard Line number
ERR07-J CERT 83

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 83 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/FilterSource.java

Rule Standard Line number
ERR07-J CERT 91

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 91 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/ImageCacheRequest.java

Rule Standard Line number
ERR05-J CERT 77

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 77 A method invocation MediaItem.getBytesBufferPool() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/LocalAlbum.java

Rule Standard Line number
ERR05-J CERT 139

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 139 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 219

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 219 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 243

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 243 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/LocalImage.java

Rule Standard Line number
ERR07-J CERT 120

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 120 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 129

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 129 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 126

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 126 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/LocalSource.java

Rule Standard Line number
ERR07-J CERT 110

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 110 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/LocalVideo.java

Rule Standard Line number
ERR07-J CERT 88

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 88 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 97

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 97 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 94

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 94 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/MediaItem.java

Rule Standard Line number
ERR07-J CERT 119

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 119 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/Path.java

Rule Standard Line number
ERR07-J CERT 130

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 130 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 144

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 144 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 159

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 159 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 173

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 173 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/SecureAlbum.java

Rule Standard Line number
ERR05-J CERT 146

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 146 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 161

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 161 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/SecureSource.java

Rule Standard Line number
ERR07-J CERT 53

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 53 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/UriSource.java

Rule Standard Line number
ERR07-J CERT 47

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 47 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/ComboSource.java

Rule Standard Line number
ERR07-J CERT 40

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 40 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/DecodeUtils.java

Rule Standard Line number
ERR05-J CERT 110

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 110 A method invocation Utils.closeSilently(fis) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/DownloadCache.java

Rule Standard Line number
ERR05-J CERT 109

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 109 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 184

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 184 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 176

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 176 code block new File(path).delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

ERR07-J CERT 207

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 207 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 218

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 218 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 330

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 330 A method invocation jc.setMode(ThreadPool.MODE_NONE) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 332

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 332 code block tempFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 332

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 332 code block tempFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 332

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 332 code block tempFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/data/DownloadUtils.java

Rule Standard Line number
ERR05-J CERT 42

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 42 A method invocation Utils.closeSilently(fos) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 76

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 76 A method invocation Utils.closeSilently(input) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/cache/ImageLoader.java

Rule Standard Line number
ERR05-J CERT 130

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 130 A method invocation Utils.closeSilently(cursor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 293

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 293 A method invocation Utils.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 334

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 334 A method invocation Utils.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 560

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 560 A method invocation Utils.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/controller/ParameterBrightness.java

Rule Standard Line number
OBJ10-J CERT 20

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 20 code block public static String sParameterType="ParameterBrightness"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/controller/ParameterColor.java

Rule Standard Line number
OBJ10-J CERT 24

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 24 code block public static String sParameterType="ParameterColor"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/controller/ParameterHue.java

Rule Standard Line number
OBJ10-J CERT 20

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 20 code block public static String sParameterType="ParameterHue"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/controller/ParameterOpacity.java

Rule Standard Line number
OBJ10-J CERT 19

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 19 code block public static String sParameterType="ParameterOpacity"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/controller/ParameterSaturation.java

Rule Standard Line number
OBJ10-J CERT 20

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 20 code block public static String sParameterType="ParameterSaturation"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/controller/ParameterStyles.java

Rule Standard Line number
OBJ10-J CERT 24

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 24 code block public static String sParameterType="ParameterStyles"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/controller/SliderHue.java

Rule Standard Line number
OBJ10-J CERT 42

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 42 code block public static String LOGTAG="SliderHue"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/data/FilterStackDBHelper.java

Rule Standard Line number
ERR05-J CERT 88

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 88 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 98

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 98 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/data/FilterStackSource.java

Rule Standard Line number
ERR05-J CERT 66

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 66 A method invocation database.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 80

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 80 A method invocation database.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 92

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 92 A method invocation database.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 103

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 103 A method invocation database.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 124

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 124 A method invocation database.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 162

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 162 A method invocation database.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 190

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 190 A method invocation database.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/editors/BasicEditor.java

Rule Standard Line number
OBJ10-J CERT 34

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 34 code block public static int ID=R.id.basicEditor; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/editors/Editor.java

Rule Standard Line number
OBJ10-J CERT 62

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 62 code block public static byte SHOW_VALUE_UNDEFINED=-1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 63

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 63 code block public static byte SHOW_VALUE_OFF=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 64

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 64 code block public static byte SHOW_VALUE_INT=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/editors/EditorRedEye.java

Rule Standard Line number
OBJ10-J CERT 31

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 31 code block public static int ID=R.id.editorRedEye; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/editors/ParametricEditor.java

Rule Standard Line number
OBJ10-J CERT 60

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 60 code block public static int ID=R.id.editorParametric; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/editors/SwapButton.java

Rule Standard Line number
OBJ10-J CERT 29

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 29 code block public static int ANIM_DURATION=200; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/filters/BaseFiltersManager.java

Rule Standard Line number
ERR02-J CERT 59

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 59 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 61

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 61 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 75

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 75 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/filters/ImageFilterDraw.java

Rule Standard Line number
NUM09-J CERT 205

NUM09-J. Do not use floating-point variables as loop counters

Floating-point variables must not be used as loop counters. Limited-precision IEEE 754 floating-point types cannot represent

  • All simple fractions exactly.
  • All decimals precisely, even when the decimals can be represented in a small number of digits.
  • All digits of large values, meaning that incrementing a large floating-point value might not change that value within the available precision.

In the given program line number 205 code block Do not use floating-point variables as loop counters ' i < len contains a floating-point variables as loop counters.

Non-compliant Solution

This noncompliant code example uses a floating-point variable as a loop counter. The decimal number 0.1 cannot be precisely represented as a float or even as a double

 
 for (float x = 0.1f; x <= 1.0f; x += 0.1f) {
  System.out.println(x);
}
 

Compliant Solution

This compliant solution uses an integer loop counter from which the desired floating-point value is derived:

 
 
for (int count = 1; count <= 10; count += 1) {
  float x = count/10.0f;
  System.out.println(x);
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/filters/ImageFilterRS.java

Rule Standard Line number
OBJ10-J CERT 34

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 34 code block public static boolean PERF_LOGGING=false; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/filters/FilterColorBorderRepresentation.java

Rule Standard Line number
OBJ10-J CERT 38

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 38 code block public static int DEFAULT_MENU_COLOR1=Color.WHITE; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 39

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 39 code block public static int DEFAULT_MENU_COLOR2=Color.BLACK; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 40

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 40 code block public static int DEFAULT_MENU_COLOR3=Color.GRAY; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 41

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 41 code block public static int DEFAULT_MENU_COLOR4=0xFFFFCCAA; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 42

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 42 code block public static int DEFAULT_MENU_COLOR5=0xFFAAAAAA; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/filters/FilterDrawRepresentation.java

Rule Standard Line number
OBJ10-J CERT 50

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 50 code block public static int DEFAULT_MENU_COLOR1=Color.RED & 0x80FFFFFF; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 51

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 51 code block public static int DEFAULT_MENU_COLOR2=Color.GREEN & 0x80FFFFFF; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 52

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 52 code block public static int DEFAULT_MENU_COLOR3=Color.BLUE & 0x80FFFFFF; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 53

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 53 code block public static int DEFAULT_MENU_COLOR4=Color.BLACK & 0x80FFFFFF; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 54

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 54 code block public static int DEFAULT_MENU_COLOR5=Color.WHITE & 0x80FFFFFF; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR02-J CERT 226

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 226 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/filters/FilterRepresentation.java

Rule Standard Line number
EXP02-J CERT 261

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 261 code block NAME_TAG.equals(rep[i][0]) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/state/StateView.java

Rule Standard Line number
OBJ10-J CERT 38

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 38 code block public static int DEFAULT=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 39

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 39 code block public static int BEGIN=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 40

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 40 code block public static int END=2; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 42

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 42 code block public static int UP=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 43

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 43 code block public static int DOWN=2; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 44

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 44 code block public static int LEFT=3; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 45

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 45 code block public static int RIGHT=4; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/tools/SaveImage.java

Rule Standard Line number
ERR05-J CERT 231

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 231 A method invocation Utils.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 260

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 260 A method invocation Utils.closeSilently(inStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 283

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 283 A method invocation Utils.closeSilently(s) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 577

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 577 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 683

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 683 code block oldSelectedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/filtershow/tools/XmpPresets.java

Rule Standard Line number
ERR05-J CERT 70

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 70 A method invocation Utils.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 102

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 102 A method invocation Utils.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR02-J CERT 129

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 129 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/gadget/LocalPhotoSource.java

Rule Standard Line number
MSC02-J CERT 108

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 108 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

ERR05-J CERT 131

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 131 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 153

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 153 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 180

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 180 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/gadget/MediaSetSource.java

Rule Standard Line number
ERR05-J CERT 157

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 157 A method invocation Binder.restoreCallingIdentity(token) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 197

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 197 A method invocation Binder.restoreCallingIdentity(token) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/gadget/PhotoAppWidgetProvider.java

Rule Standard Line number
ERR07-J CERT 49

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 49 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 73

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 73 A method invocation helper.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/gadget/WidgetConfigure.java

Rule Standard Line number
ERR05-J CERT 133

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 133 A method invocation helper.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 184

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 184 A method invocation helper.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 199

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 199 A method invocation helper.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/gadget/WidgetDatabaseHelper.java

Rule Standard Line number
ERR05-J CERT 125

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 125 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 142

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 142 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 161

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 161 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 250

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 250 A method invocation Utils.closeSilently(cursor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 274

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 274 A method invocation Utils.closeSilently(cursor) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/glrenderer/GLES11Canvas.java

Rule Standard Line number
ERR07-J CERT 913

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 913 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/glrenderer/GLES20Canvas.java

Rule Standard Line number
ERR07-J CERT 309

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 309 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 899

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 899 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/glrenderer/NinePatchChunk.java

Rule Standard Line number
ERR07-J CERT 45

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 45 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/glrenderer/NinePatchTexture.java

Rule Standard Line number
ERR07-J CERT 61

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 61 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 210

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 210 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 217

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 217 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/glrenderer/UploadedTexture.java

Rule Standard Line number
ERR05-J CERT 261

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 261 A method invocation freeBitmap() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 269

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 269 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ingest/data/ImportTask.java

Rule Standard Line number
ERR05-J CERT 102

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 102 A method invocation mWakeLock.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/provider/GalleryProvider.java

Rule Standard Line number
ERR05-J CERT 96

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 96 A method invocation Binder.restoreCallingIdentity(token) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 131

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 131 A method invocation Binder.restoreCallingIdentity(token) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 191

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 191 A method invocation Binder.restoreCallingIdentity(token) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 217

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 217 A method invocation Utils.closeSilently(pipe[1]) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/MenuExecutor.java

Rule Standard Line number
ERR05-J CERT 446

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 446 A method invocation onProgressComplete(result,mListener) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/ActionModeHandler.java

Rule Standard Line number
ERR05-J CERT 190

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 190 A method invocation root.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 206

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 206 A method invocation root.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/GLRootView.java

Rule Standard Line number
ERR05-J CERT 223

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 223 A method invocation mRenderLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 296

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 296 A method invocation mRenderLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 357

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 357 A method invocation mRenderLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 485

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 485 A method invocation mRenderLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 506

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 506 A method invocation mRenderLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/SlideshowView.java

Rule Standard Line number
MSC02-J CERT 50

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 50 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/SlotView.java

Rule Standard Line number
ERR05-J CERT 642

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 642 A method invocation root.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 702

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 702 A method invocation unlockRendering() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/SynchronizedHandler.java

Rule Standard Line number
ERR05-J CERT 38

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 38 A method invocation mRoot.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/TileImageView.java

Rule Standard Line number
ERR05-J CERT 451

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 451 A method invocation canvas.restore() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/TileImageViewAdapter.java

Rule Standard Line number
ERR05-J CERT 129

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 129 A method invocation GalleryBitmapPool.getInstance() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/DialogDetailsView.java

Rule Standard Line number
EXP02-J CERT 152

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 152 code block "1".equals(detail.getValue()) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

DCL00-J CERT 188

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 188 have DCL00-J because detail.getValue().toString().equalsIgnoreCase("0") trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

DCL00-J CERT 197

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 197 have DCL00-J because detail.getValue().toString().equalsIgnoreCase("0") trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/PhotoView.java

Rule Standard Line number
ERR07-J CERT 764

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 764 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 1658

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1658 A method invocation root.unlockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/ui/PreparePageFadeoutTexture.java

Rule Standard Line number
ERR05-J CERT 77

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 77 A method invocation root.lockRenderThread() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/util/Profile.java

Rule Standard Line number
MSC02-J CERT 67

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 67 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/util/ProfileData.java

Rule Standard Line number
ERR05-J CERT 123

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 123 A method invocation Utils.closeSilently(mOut) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/gallery3d/util/SaveVideoFileUtils.java

Rule Standard Line number
ERR05-J CERT 69

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 69 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/photos/data/PhotoDatabase.java

Rule Standard Line number
ERR05-J CERT 155

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 155 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 192

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 192 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/photos/data/SQLiteContentProvider.java

Rule Standard Line number
ERR05-J CERT 127

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 127 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 151

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 151 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 171

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 171 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 194

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 194 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 240

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 240 A method invocation onEndTransaction(callerIsSyncAdapter) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/photos/drawables/AutoThumbnailDrawable.java

Rule Standard Line number
ERR05-J CERT 291

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 291 A method invocation scheduleSelf(mUpdateBitmap,0) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/photos/GalleryActivity.java

Rule Standard Line number
ERR07-J CERT 83

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 83 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/photos/MultiSelectGridFragment.java

Rule Standard Line number
ERR07-J CERT 291

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 291 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 297

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 297 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/photos/views/BlockingGLTextureView.java

Rule Standard Line number
ERR07-J CERT 160

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 160 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 168

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 168 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 197

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 197 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 200

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 200 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 203

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 203 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 294

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 294 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src/com/android/photos/views/TiledImageRenderer.java

Rule Standard Line number
ERR05-J CERT 456

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 456 A method invocation canvas.restore() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Gallery2/src_pd/com/android/gallery3d/picasasource/PicasaSource.java

Rule Standard Line number
ERR07-J CERT 80

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 80 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/InCallUI/src/com/android/incallui/CallerInfoAsyncQuery.java

Rule Standard Line number
ERR05-J CERT 315

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 315 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/InCallUI/src/com/android/incallui/VideoCallPresenter.java

Rule Standard Line number
ERR05-J CERT 1253

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1253 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/KeyChain/src/com/android/keychain/KeyChainActivity.java

Rule Standard Line number
ERR05-J CERT 456

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 456 A method invocation connection.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/KeyChain/src/com/android/keychain/KeyChainService.java

Rule Standard Line number
ERR05-J CERT 424

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 424 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/AppsCustomizePagedView.java

Rule Standard Line number
ERR05-J CERT 1128

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1128 A method invocation data.cleanup(true) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1326

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1326 A method invocation data.cleanup(false) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/AppsCustomizeTabHost.java

Rule Standard Line number
ERR07-J CERT 458

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 458 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/CellLayout.java

Rule Standard Line number
ERR07-J CERT 984

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 984 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 3136

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 3136 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/LauncherProvider.java

Rule Standard Line number
ERR07-J CERT 136

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 136 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 176

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 176 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 423

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 423 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 491

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 491 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 515

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 515 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 546

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 546 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 626

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 626 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 703

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 703 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 761

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 761 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 773

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 773 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 793

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 793 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 878

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 878 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 950

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 950 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1010

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1010 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1174

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1174 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1177

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1177 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/LauncherViewPropertyAnimator.java

Rule Standard Line number
ERR07-J CERT 76

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 76 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 81

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 81 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 179

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 179 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/PagedViewCellLayout.java

Rule Standard Line number
ERR07-J CERT 178

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 178 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/PagedViewCellLayoutChildren.java

Rule Standard Line number
ERR07-J CERT 86

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 86 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/FolderIcon.java

Rule Standard Line number
OBJ10-J CERT 79

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 79 code block public static Drawable sSharedFolderLeaveBehind=null; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 172

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 172 code block public static Drawable sSharedOuterRingDrawable=null; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 173

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 173 code block public static Drawable sSharedInnerRingDrawable=null; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 174

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 174 code block public static int sPreviewSize=-1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 175

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 175 code block public static int sPreviewPadding=-1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/HolographicOutlineHelper.java

Rule Standard Line number
ERR07-J CERT 134

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 134 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 163

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 163 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/UninstallShortcutReceiver.java

Rule Standard Line number
ERR05-J CERT 129

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 129 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/Utilities.java

Rule Standard Line number
ERR07-J CERT 174

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 174 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
MSC02-J CERT 273

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 273 code block new Random(System.currentTimeMillis()) trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/WidgetPreviewLoader.java

Rule Standard Line number
ERR07-J CERT 248

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 248 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 281

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 281 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 447

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 447 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 650

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 650 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/Workspace.java

Rule Standard Line number
ERR07-J CERT 2766

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 2766 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/LauncherModel.java

Rule Standard Line number
ERR07-J CERT 229

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 229 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 509

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 509 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 557

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 557 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 599

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 599 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 1082

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1082 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1088

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1088 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1094

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1094 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 1504

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1504 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/DragController.java

Rule Standard Line number
OBJ10-J CERT 46

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 46 code block /** * Indicates the drag is a move. */ public static int DRAG_ACTION_MOVE=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 49

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 49 code block /** * Indicates the drag is a copy. */ public static int DRAG_ACTION_COPY=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher2/src/com/android/launcher2/Launcher.java

Rule Standard Line number
ERR08-J CERT 1623

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 1623 catch block contains a null pointer exception NullPointerException ex

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR07-J CERT 2672

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 2672 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/allapps/AllAppsContainerView.java

Rule Standard Line number
ERR07-J CERT 234

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 234 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/allapps/AllAppsGridAdapter.java

Rule Standard Line number
ERR07-J CERT 494

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 494 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/allapps/AllAppsRecyclerView.java

Rule Standard Line number
ERR07-J CERT 226

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 226 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 257

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 257 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/AppWidgetsRestoredReceiver.java

Rule Standard Line number
ERR05-J CERT 76

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 76 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/AutoInstallsLayout.java

Rule Standard Line number
ERR07-J CERT 503

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 503 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 506

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 506 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 601

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 601 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/ItemInfo.java

Rule Standard Line number
ERR07-J CERT 149

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 149 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 173

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 173 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/Launcher.java

Rule Standard Line number
ERR08-J CERT 2002

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 2002 catch block contains a null pointer exception NullPointerException ex

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR07-J CERT 3785

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 3785 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 3798

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 3798 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR02-J CERT 4360

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 4360 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 4695

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 4695 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 4715

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 4715 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/LauncherAppWidgetHost.java

Rule Standard Line number
ERR07-J CERT 78

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 78 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/LauncherBackupHelper.java

Rule Standard Line number
ERR05-J CERT 478

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 478 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 528

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 528 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 615

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 615 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 701

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 701 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/MemoryDumpActivity.java

Rule Standard Line number
ERR05-J CERT 65

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 65 A method invocation is.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/model/MigrateFromRestoreTask.java

Rule Standard Line number
OBJ10-J CERT 40

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 40 code block public static boolean ENABLED=false; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR07-J CERT 680

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 680 throws Exception

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/DragController.java

Rule Standard Line number
OBJ10-J CERT 48

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 48 code block /** * Indicates the drag is a move. */ public static int DRAG_ACTION_MOVE=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 51

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 51 code block /** * Indicates the drag is a copy. */ public static int DRAG_ACTION_COPY=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/DragView.java

Rule Standard Line number
OBJ10-J CERT 41

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 41 code block public static int COLOR_CHANGE_DURATION=120; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/Stats.java

Rule Standard Line number
ERR07-J CERT 75

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 75 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/util/FocusLogic.java

Rule Standard Line number
NUM09-J CERT 331

NUM09-J. Do not use floating-point variables as loop counters

Floating-point variables must not be used as loop counters. Limited-precision IEEE 754 floating-point types cannot represent

  • All simple fractions exactly.
  • All decimals precisely, even when the decimals can be represented in a small number of digits.
  • All digits of large values, meaning that incrementing a large floating-point value might not change that value within the available precision.

In the given program line number 331 code block Do not use floating-point variables as loop counters ' 0 <= i && i < cntX contains a floating-point variables as loop counters.

Non-compliant Solution

This noncompliant code example uses a floating-point variable as a loop counter. The decimal number 0.1 cannot be precisely represented as a float or even as a double

 
 for (float x = 0.1f; x <= 1.0f; x += 0.1f) {
  System.out.println(x);
}
 

Compliant Solution

This compliant solution uses an integer loop counter from which the desired floating-point value is derived:

 
 
for (int count = 1; count <= 10; count += 1) {
  float x = count/10.0f;
  System.out.println(x);
}
 

Additional information

Related Guidelines

NUM09-J CERT 392

NUM09-J. Do not use floating-point variables as loop counters

Floating-point variables must not be used as loop counters. Limited-precision IEEE 754 floating-point types cannot represent

  • All simple fractions exactly.
  • All decimals precisely, even when the decimals can be represented in a small number of digits.
  • All digits of large values, meaning that incrementing a large floating-point value might not change that value within the available precision.

In the given program line number 392 code block Empty infinite loop contains a floating-point variables as loop counters.

Non-compliant Solution

This noncompliant code example uses a floating-point variable as a loop counter. The decimal number 0.1 cannot be precisely represented as a float or even as a double

 
 for (float x = 0.1f; x <= 1.0f; x += 0.1f) {
  System.out.println(x);
}
 

Compliant Solution

This compliant solution uses an integer loop counter from which the desired floating-point value is derived:

 
 
for (int count = 1; count <= 10; count += 1) {
  float x = count/10.0f;
  System.out.println(x);
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/WidgetPreviewLoader.java

Rule Standard Line number
ERR05-J CERT 321

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 321 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 454

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 454 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 502

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 502 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 504

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 504 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/Workspace.java

Rule Standard Line number
ERR07-J CERT 554

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 554 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 604

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 604 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 632

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 632 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 977

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 977 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 3156

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 3156 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 3776

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 3776 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
DCL00-J CERT 4151

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 4151 have DCL00-J because mapOverItems(MAP_RECURSE,new ItemOperator(){ @Override public boolean evaluate( ItemInfo info, View v, View parent){ if (info instanceof ShortcutInfo && v instanceof BubbleTextView) { ShortcutInfo shortcutInfo=(ShortcutInfo)info; ComponentName cn=shortcutInfo.getTargetComponent(); if (user.equals(shortcutInfo.user) && cn != null && packageNames.contains(cn.getPackageName())) { shortcutInfo.isDisabled|=reason; BubbleTextView shortcut=(BubbleTextView)v; shortcut.applyFromShortcutInfo(shortcutInfo,mIconCache); if (parent != null) { parent.invalidate(); } } } return false; } } ) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/compat/AlphabeticIndexCompat.java

Rule Standard Line number
ERR02-J CERT 82

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 82 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 107

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 107 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 151

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 151 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 165

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 165 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/InvariantDeviceProfile.java

Rule Standard Line number
ERR07-J CERT 101

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 101 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/LauncherModel.java

Rule Standard Line number
OBJ10-J CERT 170

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 170 code block public static HashMap sBgWidgetProviders; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR07-J CERT 384

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 384 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 538

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 538 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 584

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 584 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR02-J CERT 729

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 729 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR07-J CERT 887

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 887 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 973

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 973 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 1161

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1161 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 1416

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1416 A method invocation sc.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 1504

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1504 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1510

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1510 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1516

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1516 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/LauncherProvider.java

Rule Standard Line number
ERR07-J CERT 131

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 131 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 134

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 134 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 202

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 202 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 221

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 221 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 313

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 313 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 649

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 649 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 666

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 666 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 801

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 801 A method invocation updateStmt.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 849

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 849 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 827

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 827 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 881

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 881 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 905

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 905 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 918

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 918 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 953

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 953 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1064

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1064 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 1356

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1356 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1333

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1333 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1350

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1350 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 1388

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1388 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/LauncherViewPropertyAnimator.java

Rule Standard Line number
ERR07-J CERT 77

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 77 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 82

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 82 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 180

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 180 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/FolderIcon.java

Rule Standard Line number
OBJ10-J CERT 91

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 91 code block public static Drawable sSharedFolderLeaveBehind=null; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 202

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 202 code block public static Drawable sSharedOuterRingDrawable=null; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 203

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 203 code block public static Drawable sSharedInnerRingDrawable=null; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 204

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 204 code block public static int sPreviewSize=-1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 205

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 205 code block public static int sPreviewPadding=-1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR07-J CERT 218

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 218 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/IconCache.java

Rule Standard Line number
ERR05-J CERT 708

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 708 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Launcher3/src/com/android/launcher3/CellLayout.java

Rule Standard Line number
ERR07-J CERT 834

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 834 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 2732

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 2732 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/LegacyCamera/src/com/android/camera/Camera.java

Rule Standard Line number
ERR05-J CERT 1080

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1080 A method invocation Util.closeSilently(f) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1394

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1394 A method invocation Util.closeSilently(outputStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1424

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1424 A method invocation Util.closeSilently(tempStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 1410

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 1410 code block path.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 1640

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 1640 code block path.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 1640

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 1640 code block path.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

ERR07-J CERT 1818

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1818 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1867

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1867 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/LegacyCamera/src/com/android/camera/CameraErrorCallback.java

Rule Standard Line number
ERR07-J CERT 31

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 31 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/LegacyCamera/src/com/android/camera/CameraHolder.java

Rule Standard Line number
ERR07-J CERT 164

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 164 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/LegacyCamera/src/com/android/camera/EffectsRecorder.java

Rule Standard Line number
ERR07-J CERT 147

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 147 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 149

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 149 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 151

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 151 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 162

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 162 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 164

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 164 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 174

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 174 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 176

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 176 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 188

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 188 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 190

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 190 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 208

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 208 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 210

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 210 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 224

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 224 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 226

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 226 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 237

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 237 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 239

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 239 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 254

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 254 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 256

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 256 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 282

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 282 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 284

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 284 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 345

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 345 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 360

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 360 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 369

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 369 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 381

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 381 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 383

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 383 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 393

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 393 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 395

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 395 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 457

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 457 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 476

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 476 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 519

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 519 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 521

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 521 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 527

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 527 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 530

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 530 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 533

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 533 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 541

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 541 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 588

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 588 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 603

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 603 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 647

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 647 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 649

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 649 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 655

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 655 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 710

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 710 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 729

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 729 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 744

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 744 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 788

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 788 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/LegacyCamera/src/com/android/camera/OnScreenHint.java

Rule Standard Line number
ERR07-J CERT 85

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 85 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 128

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 128 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 133

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 133 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/LegacyCamera/src/com/android/camera/panorama/PanoramaActivity.java

Rule Standard Line number
ERR07-J CERT 794

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 794 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 844

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 844 A method invocation mPartialWakeLock.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 1103

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1103 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1124

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1124 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/LegacyCamera/src/com/android/camera/Thumbnail.java

Rule Standard Line number
ERR05-J CERT 120

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 120 A method invocation Util.closeSilently(d) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 147

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 147 A method invocation Util.closeSilently(d) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 215

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 215 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 241

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 241 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/LegacyCamera/src/com/android/camera/ui/OnIndicatorEventListener.java

Rule Standard Line number
OBJ10-J CERT 20

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 20 code block public static int EVENT_ENTER_SECOND_LEVEL_INDICATOR_BAR=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 21

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 21 code block public static int EVENT_LEAVE_SECOND_LEVEL_INDICATOR_BAR=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 22

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 22 code block public static int EVENT_ENTER_ZOOM_CONTROL=2; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 23

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 23 code block public static int EVENT_LEAVE_ZOOM_CONTROL=3; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/LegacyCamera/src/com/android/camera/Util.java

Rule Standard Line number
ERR07-J CERT 272

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 272 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/LegacyCamera/src/com/android/camera/VideoCamera.java

Rule Standard Line number
ERR07-J CERT 906

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 906 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 933

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 933 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1265

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1265 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 2055

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 2055 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/ManagedProvisioning/src/com/android/managedprovisioning/HomeReceiverActivity.java

Rule Standard Line number
ERR05-J CERT 58

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 58 A method invocation disableComponent(new ComponentName(this,HomeReceiverActivity.class)) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/android/support/v7/mms/DefaultApnSettingsLoader.java

Rule Standard Line number
ERR05-J CERT 332

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 332 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 433

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 433 A method invocation xml.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
DCL00-J CERT 405

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 405 have DCL00-J because new ApnsXmlParser(xml,new ApnsXmlParser.ApnProcessor(){ @Override public void process( ContentValues apnValues){ final String mcc=trimWithNullCheck(apnValues.getAsString(APN_MCC)); final String mnc=trimWithNullCheck(apnValues.getAsString(APN_MNC)); final String apn=trimWithNullCheck(apnValues.getAsString(APN_APN)); try { if (mccMnc[0] == Integer.parseInt(mcc) && mccMnc[1] == Integer.parseInt(mnc) && (TextUtils.isEmpty(apnName) || apnName.equalsIgnoreCase(apn))) { final String type=apnValues.getAsString(APN_TYPE); final String mmsc=apnValues.getAsString(APN_MMSC); final String mmsproxy=apnValues.getAsString(APN_MMSPROXY); final String mmsport=apnValues.getAsString(APN_MMSPORT); final Apn newApn=MemoryApn.from(apns,type,mmsc,mmsproxy,mmsport); if (newApn != null) { apns.add(newApn); } } } catch ( final NumberFormatException e) { } } } ).parse() trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/android/support/v7/mms/DefaultCarrierConfigValuesLoader.java

Rule Standard Line number
ERR05-J CERT 122

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 122 A method invocation xml.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/android/support/v7/mms/MmsHttpClient.java

Rule Standard Line number
ERR05-J CERT 219

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 219 A method invocation connection.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/android/support/v7/mms/MmsNetworkManager.java

Rule Standard Line number
ERR05-J CERT 174

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 174 A method invocation unregisterConnectivityChangeReceiverLocked() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/android/support/v7/mms/MmsRequest.java

Rule Standard Line number
ERR05-J CERT 205

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 205 A method invocation networkManager.releaseNetwork() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/android/support/v7/mms/MmsService.java

Rule Standard Line number
ERR05-J CERT 343

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 343 A method invocation releaseService() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/android/support/v7/mms/pdu/EncodedStringValue.java

Rule Standard Line number
ERR02-J CERT 176

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 176 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 200

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 200 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR08-J CERT 219

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 219 catch block contains a null pointer exception NullPointerException _

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/android/support/v7/mms/pdu/PduHeaders.java

Rule Standard Line number
ERR07-J CERT 488

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 488 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 537

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 537 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 601

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 601 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 632

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 632 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 661

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 661 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 715

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 715 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/android/support/v7/mms/pdu/PduParser.java

Rule Standard Line number
ERR08-J CERT 406

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 406 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 435

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 435 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 466

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 466 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 474

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 474 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 548

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 548 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 558

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 558 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 570

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 570 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 608

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 608 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 621

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 621 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 677

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 677 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 793

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 793 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR07-J CERT 1012

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1012 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1273

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1273 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
DCL00-J CERT 1725

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 1725 have DCL00-J because PduPart.CONTENT_TRANSFER_ENCODING.equalsIgnoreCase(new String(tempHeader)) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/android/support/v7/mms/pdu/SendReq.java

Rule Standard Line number
ERR07-J CERT 39

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 39 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/MarkAsReadAction.java

Rule Standard Line number
ERR05-J CERT 84

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 84 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/SendMessageAction.java

Rule Standard Line number
ERR05-J CERT 270

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 270 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 415

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 415 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/ActionServiceImpl.java

Rule Standard Line number
ERR05-J CERT 291

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 291 A method invocation sWakeLock.release(intent,opcode) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 285

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 285 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/BackgroundWorkerService.java

Rule Standard Line number
ERR05-J CERT 131

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 131 A method invocation sWakeLock.release(intent,opcode) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 128

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 128 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/DumpDatabaseAction.java

Rule Standard Line number
ERR05-J CERT 96

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 96 A method invocation LogUtil.i(TAG,"Dump complete; orig size: " + originalSize + ", copy size: "+ totalBytes) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/FixupMessageStatusOnStartupAction.java

Rule Standard Line number
ERR05-J CERT 83

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 83 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/InsertNewMessageAction.java

Rule Standard Line number
ERR05-J CERT 328

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 328 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 405

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 405 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/LogTelephonyDatabaseAction.java

Rule Standard Line number
ERR05-J CERT 101

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 101 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 126

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 126 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/MarkAsSeenAction.java

Rule Standard Line number
ERR05-J CERT 97

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 97 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/ProcessDeliveryReportAction.java

Rule Standard Line number
ERR05-J CERT 96

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 96 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/ProcessDownloadedMmsAction.java

Rule Standard Line number
FIO02-J CERT 259

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 259 code block downloadedFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

ERR05-J CERT 528

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 528 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/ProcessPendingMessagesAction.java

Rule Standard Line number
ERR05-J CERT 377

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 377 A method invocation sending.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 436

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 436 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/ProcessSentMessageAction.java

Rule Standard Line number
FIO02-J CERT 146

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 146 code block tempFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/ReceiveMmsMessageAction.java

Rule Standard Line number
ERR05-J CERT 130

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 130 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/ReceiveSmsMessageAction.java

Rule Standard Line number
ERR05-J CERT 155

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 155 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/SyncCursorPair.java

Rule Standard Line number
ERR07-J CERT 457

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 457 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 474

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 474 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 707

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 707 A method invocation remoteMmsCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/SyncMessageBatch.java

Rule Standard Line number
ERR05-J CERT 112

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 112 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 314

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 314 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 331

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 331 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/SyncMessagesAction.java

Rule Standard Line number
ERR05-J CERT 333

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 333 A method invocation cursors.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 569

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 569 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/UpdateConversationArchiveStatusAction.java

Rule Standard Line number
ERR05-J CERT 64

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 64 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/UpdateConversationOptionsAction.java

Rule Standard Line number
ERR05-J CERT 129

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 129 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/action/UpdateMessagePartSizeAction.java

Rule Standard Line number
ERR05-J CERT 77

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 77 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/BugleDatabaseOperations.java

Rule Standard Line number
ERR05-J CERT 238

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 238 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 274

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 274 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 310

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 310 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 344

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 344 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 527

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 527 A method invocation dbWrapper.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 551

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 551 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 710

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 710 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 736

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 736 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 884

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 884 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 933

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 933 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 956

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 956 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 997

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 997 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1029

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1029 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1052

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1052 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1075

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1075 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1123

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1123 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1260

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1260 A method invocation dbWrapper.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1302

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1302 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1345

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1345 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1381

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1381 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1484

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1484 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1621

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1621 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1700

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1700 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1718

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1718 A method invocation dbWrapper.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1799

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1799 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1829

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1829 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1879

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1879 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/BugleNotifications.java

Rule Standard Line number
ERR05-J CERT 523

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 523 A method invocation avatarHiRes.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 761

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 761 A method invocation imageResource.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/data/ConversationData.java

Rule Standard Line number
ERR05-J CERT 99

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 99 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/data/ConversationListItemData.java

Rule Standard Line number
ERR05-J CERT 486

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 486 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/data/DraftMessageData.java

Rule Standard Line number
OBJ10-J CERT 73

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 73 code block public static int ATTACHMENTS_CHANGED=0x0001; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 74

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 74 code block public static int MESSAGE_TEXT_CHANGED=0x0002; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 75

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 75 code block public static int MESSAGE_SUBJECT_CHANGED=0x0004; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 77

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 77 code block public static int SELF_CHANGED=0x0008; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 78

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 78 code block public static int ALL_CHANGED=0x00FF; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 82

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 82 code block public static int WIDGET_CHANGED=0x0100; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/data/ParticipantData.java

Rule Standard Line number
ERR05-J CERT 162

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 162 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/DatabaseHelper.java

Rule Standard Line number
ERR05-J CERT 697

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 697 A method invocation tableCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 728

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 728 A method invocation triggerCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 746

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 746 A method invocation viewCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 772

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 772 A method invocation indexCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/DatabaseWrapper.java

Rule Standard Line number
ERR05-J CERT 239

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 239 A method invocation planCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/FileProvider.java

Rule Standard Line number
MSC02-J CERT 37

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 37 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/media/CompositeImageRequest.java

Rule Standard Line number
ERR05-J CERT 92

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 92 A method invocation resource.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/media/NetworkUriImageRequest.java

Rule Standard Line number
ERR05-J CERT 75

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 75 A method invocation connection.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 115

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 115 A method invocation connection.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/media/PoolableImageCache.java

Rule Standard Line number
ERR05-J CERT 329

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 329 A method invocation imageToUse.releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/media/RefCountedMediaResource.java

Rule Standard Line number
ERR05-J CERT 75

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 75 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 101

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 101 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 110

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 110 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 119

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 119 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 128

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 128 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/media/VideoThumbnailRequest.java

Rule Standard Line number
ERR05-J CERT 71

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 71 A method invocation retriever.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/media/DecodedImageResource.java

Rule Standard Line number
ERR05-J CERT 59

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 59 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 77

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 77 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 94

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 94 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 118

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 118 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 131

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 131 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 142

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 142 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 230

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 230 A method invocation release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/media/EncodedImageResource.java

Rule Standard Line number
ERR05-J CERT 59

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 59 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 69

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 69 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 137

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 137 A method invocation release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/media/GifImageResource.java

Rule Standard Line number
ERR05-J CERT 106

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 106 A method invocation releaseLock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/media/ImageRequest.java

Rule Standard Line number
ERR07-J CERT 116

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 116 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 122

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 122 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 168

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 168 A method invocation inputStream.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 211

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 211 A method invocation inputStream.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/media/MediaResourceManager.java

Rule Standard Line number
ERR05-J CERT 153

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 153 A method invocation loadResult.scheduleChainedRequests() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 269

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 269 A method invocation result.scheduleChainedRequests() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/MessageNotificationState.java

Rule Standard Line number
ERR05-J CERT 750

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 750 A method invocation convMessageCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1338

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1338 A method invocation messageDataCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/datamodel/ParticipantRefresh.java

Rule Standard Line number
ERR05-J CERT 289

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 289 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 331

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 331 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 405

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 405 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 484

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 484 A method invocation selfCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 563

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 563 A method invocation matchingContactCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 621

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 621 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 649

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 649 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 687

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 687 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 706

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 706 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/mmslib/pdu/EncodedStringValue.java

Rule Standard Line number
ERR02-J CERT 191

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 191 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 215

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 215 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR08-J CERT 234

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 234 catch block contains a null pointer exception NullPointerException exception

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/mmslib/pdu/PduComposer.java

Rule Standard Line number
ERR08-J CERT 478

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 478 catch block contains a null pointer exception final NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR02-J CERT 951

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 951 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR07-J CERT 1083

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1083 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1121

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1121 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1149

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1149 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/mmslib/pdu/PduHeaders.java

Rule Standard Line number
ERR07-J CERT 508

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 508 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 557

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 557 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 621

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 621 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 652

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 652 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 681

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 681 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 735

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 735 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/mmslib/pdu/PduParser.java

Rule Standard Line number
ERR08-J CERT 432

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 432 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 462

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 462 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 492

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 492 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 500

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 500 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 574

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 574 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 584

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 584 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 597

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 597 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 636

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 636 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 649

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 649 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 707

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 707 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 826

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 826 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR07-J CERT 1046

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1046 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1310

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1310 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
DCL00-J CERT 1760

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 1760 have DCL00-J because PduPart.CONTENT_TRANSFER_ENCODING.equalsIgnoreCase(new String(tempHeader)) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/mmslib/pdu/PduPersister.java

Rule Standard Line number
ERR05-J CERT 492

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 492 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 531

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 531 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 630

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 630 A method invocation PDU_CACHE_INSTANCE.notifyAll() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 606

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 606 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1002

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1002 A method invocation f.getName() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1046

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1046 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1288

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1288 A method invocation PDU_CACHE_INSTANCE.notifyAll() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/mmslib/pdu/SendReq.java

Rule Standard Line number
ERR07-J CERT 41

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 41 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/receiver/SendStatusReceiver.java

Rule Standard Line number
ERR08-J CERT 87

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 87 catch block contains a null pointer exception final NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/receiver/SmsReceiver.java

Rule Standard Line number
ERR08-J CERT 360

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 360 catch block contains a null pointer exception final NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/sms/ApnDatabase.java

Rule Standard Line number
ERR05-J CERT 206

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 206 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 267

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 267 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 350

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 350 A method invocation parser.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/sms/BugleApnSettingsLoader.java

Rule Standard Line number
ERR05-J CERT 261

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 261 A method invocation database.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 430

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 430 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 521

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 521 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 641

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 641 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/sms/BugleCarrierConfigValuesLoader.java

Rule Standard Line number
ERR05-J CERT 147

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 147 A method invocation parser.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/sms/DatabaseMessages.java

Rule Standard Line number
EXP02-J CERT 311

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 311 code block Assert.equals(INDEX_SUB_ID,projection.length - 1) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

ERR05-J CERT 673

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 673 A method invocation LogUtil.e(TAG,"DatabaseMessages.MmsPart: close file failed: " + e,e) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 753

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 753 A method invocation retriever.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 776

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 776 A method invocation LogUtil.e(TAG,"DatabaseMessages.MmsPart: failed to close " + e,e) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/sms/MmsSender.java

Rule Standard Line number
FIO02-J CERT 195

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 195 code block tempFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 202

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 202 code block tempFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/sms/MmsSmsUtils.java

Rule Standard Line number
DCL02-J CERT 173

DCL02-J. Do not modify the collection's elements during an enhanced for statement

Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement. Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.

In the given program line number 173 code block contains recipient trying to modify the collection's elements during an enhanced for statement

Non-compliant Solution

This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:

 
List list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;
 
System.out.println("Processing list...");
for (Integer i: list) {
  if (first) {
    first = false;
    i = new Integer(99);
  }
  System.out.println(" New item: " + i);
  // Process i
}
 
System.out.println("Modified list?");
for (Integer i: list) {
  System.out.println("List item: " + i);
}
 

Compliant Solution

This compliant solution processes the "modified" list but leaves the actual list unchanged:

 
// ...
 
for (final Integer i: list) {
  Integer item = i;
  if (first) {
    first = false;
    item = new Integer(99);
  }
  System.out.println(" New item: " + item);
  // Process item
}
 
// ...
 

Additional information

ERR05-J CERT 195

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 195 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/sms/MmsUtils.java

Rule Standard Line number
ERR05-J CERT 415

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 415 A method invocation retriever.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 622

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 622 A method invocation LogUtil.e(TAG,"getDataLength couldn't close: " + uri,e) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 706

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 706 A method invocation LogUtil.e(TAG,"MmsUtils.getMediaFileSize: failed to close " + e,e) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 754

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 754 A method invocation thread.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 801

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 801 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR08-J CERT 1060

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 1060 catch block contains a null pointer exception final NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR05-J CERT 1287

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1287 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1512

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1512 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1549

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1549 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1578

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1578 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1650

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1650 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1682

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1682 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1718

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1718 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2235

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2235 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2714

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2714 A method invocation bos.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/sms/SmsSender.java

Rule Standard Line number
MSC02-J CERT 65

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 65 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/ui/conversationlist/ShareIntentActivity.java

Rule Standard Line number
ERR05-J CERT 155

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 155 A method invocation retriever.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/ui/appsettings/ApnEditorActivity.java

Rule Standard Line number
EXP02-J CERT 363

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 363 code block new AsyncTask(){ @Override protected Void doInBackground( Void... params){ ContentValues values=new ContentValues(); values.put(Telephony.Carriers.NAME,name.length() < 1 ? getResources().getString(R.string.untitled_apn) : name); values.put(Telephony.Carriers.MMSPROXY,checkNotSet(mMmsProxy.getText())); values.put(Telephony.Carriers.MMSPORT,checkNotSet(mMmsPort.getText())); values.put(Telephony.Carriers.MMSC,checkNotSet(mMmsc.getText())); values.put(Telephony.Carriers.TYPE,BugleApnSettingsLoader.APN_TYPE_MMS); values.put(Telephony.Carriers.MCC,mcc); values.put(Telephony.Carriers.MNC,mnc); values.put(Telephony.Carriers.NUMERIC,mcc + mnc); if (mCurMnc != null && mCurMcc != null) { if (mCurMnc.equals(mnc) && mCurMcc.equals(mcc)) { values.put(Telephony.Carriers.CURRENT,1); } } if (mNewApn) { mDatabase.insert(ApnDatabase.APN_TABLE,null,values); } else { String selection=Telephony.Carriers._ID + " =?"; String[] selectionArgs=new String[]{mCurrentId}; int updated=mDatabase.update(ApnDatabase.APN_TABLE,values,selection,selectionArgs); } return null; } } .execute((Void)null) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/ui/appsettings/ApnSettingsActivity.java

Rule Standard Line number
ERR05-J CERT 265

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 265 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/AccessibilityUtil.java

Rule Standard Line number
OBJ10-J CERT 33

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 33 code block public static String sContentDescriptionDivider; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/exif/ExifInterface.java

Rule Standard Line number
ERR05-J CERT 1049

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1049 A method invocation closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1115

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1115 A method invocation is.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/exif/ExifModifier.java

Rule Standard Line number
ERR05-J CERT 62

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 62 A method invocation ExifInterface.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 136

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 136 A method invocation ExifInterface.closeSilently(is) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/exif/ExifTag.java

Rule Standard Line number
EXP02-J CERT 992

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 992 code block mValue.equals(tag.mValue) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/ImageUtils.java

Rule Standard Line number
ERR05-J CERT 238

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 238 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 287

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 287 A method invocation LogUtil.e(TAG,"getOrientation error closing input stream",e) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 554

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 554 A method invocation mDecoded.recycle() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR08-J CERT 583

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 583 catch block contains a null pointer exception final NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/MediaMetadataRetrieverWrapper.java

Rule Standard Line number
ERR05-J CERT 50

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 50 A method invocation fd.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/NotificationPlayer.java

Rule Standard Line number
ERR07-J CERT 343

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 343 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/SafeAsyncTask.java

Rule Standard Line number
ERR05-J CERT 120

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 120 A method invocation Assert.fail(this + " took too long") is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 168

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 168 A method invocation sWakeLock.release(intent,WAKELOCK_OP) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/ContactUtil.java

Rule Standard Line number
ERR05-J CERT 423

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 423 A method invocation nameCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/ContentType.java

Rule Standard Line number
OBJ10-J CERT 23

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 23 code block public static String THREE_GPP_EXTENSION="3gp"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 24

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 24 code block public static String VIDEO_MP4_EXTENSION="mp4"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 26

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 26 code block public static String DEFAULT_EXTENSION="dat"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/Dates.java

Rule Standard Line number
ERR08-J CERT 79

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 79 catch block contains a null pointer exception final NullPointerException npe

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/DebugUtils.java

Rule Standard Line number
ERR05-J CERT 262

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 262 A method invocation ensureReadable(dumpFile) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 320

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 320 code block file.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 320

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 320 code block file.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 320

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 320 code block file.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 320

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 320 code block file.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 320

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 320 code block file.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

ERR05-J CERT 347

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 347 A method invocation bis.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/util/UriUtil.java

Rule Standard Line number
ERR05-J CERT 172

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 172 A method invocation retriever.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 215

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 215 A method invocation LogUtil.e(LogUtil.BUGLE_TAG,"error trying to close the inputStream",e) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 272

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 272 A method invocation LogUtil.e(LogUtil.BUGLE_TAG,"error trying to close the inputStream",e) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR04-J CERT 296

ERR04-J. Do not complete abruptly from a finally block

Never use return, break, continue, or throw statements within a finally block. When program execution enters a try block that has a finally block, the finally block always executes regardless of whether the try block (or any associated catch blocks) executes to normal completion. Statements that cause the finally block to complete abruptly also cause the try block to complete abruptly and consequently suppress any exception thrown from the try or catch blocks.

In the given program line number 296 An abruptly statement return null; is present in finally block

Non-compliant Solution

In this noncompliant code example, the finally block completes abruptly because of a return statement in the block

 
 class TryNC {
  private static boolean doSomeThing() {
    try {
      throw new IllegalStateException();
    } finally {
      System.out.println("Done");
      return true;
    }
  }
}
 

Compliant Solution

This compliant solution removes the return statement from the finally block

 
 class TryNC {
  private static boolean doSomeThing() {
    try {
      throw new IllegalStateException();
    } finally {
      System.out.println("logic done");
     
    }
    //Add return statement here
  }
}

Additional information

Related Guidelines

ERR05-J CERT 353

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 353 A method invocation LogUtil.w(LogUtil.BUGLE_TAG,"Failed to close afd for " + contentUri) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/widget/BaseWidgetFactory.java

Rule Standard Line number
ERR05-J CERT 112

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 112 A method invocation Binder.restoreCallingIdentity(token) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Messaging/src/com/android/messaging/widget/WidgetConversationProvider.java

Rule Standard Line number
ERR05-J CERT 292

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 292 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Music/src/com/android/music/MediaPlaybackActivity.java

Rule Standard Line number
ERR08-J CERT 280

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 280 catch block contains a null pointer exception NullPointerException ex

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR07-J CERT 344

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 344 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Music/src/com/android/music/ArtistAlbumBrowserActivity.java

Rule Standard Line number
EXP02-J CERT 798

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 798 code block MediaStore.Audio.Albums.ARTIST.equals(name) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Music/src/com/android/music/MediaPlaybackService.java

Rule Standard Line number
MSC02-J CERT 1535

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 1535 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

ERR05-J CERT 1567

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1567 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Music/src/com/android/music/MusicUtils.java

Rule Standard Line number
OBJ10-J CERT 153

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 153 code block public static IMediaPlaybackService sService=null; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 398

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 398 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 826

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 826 A method invocation context.startActivity(intent) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR02-J CERT 887

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 887 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR05-J CERT 1137

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1137 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Music/src/com/android/music/PlaylistBrowserActivity.java

Rule Standard Line number
ERR05-J CERT 433

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 433 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 458

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 458 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/MusicFX/src/com/android/musicfx/ControlPanelEffect.java

Rule Standard Line number
ERR05-J CERT 194

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 194 A method invocation mediaPlayer.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 262

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 262 A method invocation Arrays.copyOf(EQUALIZER_PRESET_USER_BAND_LEVEL_DEFAULT,mEQNumBands) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR08-J CERT 1013

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 1013 catch block contains a null pointer exception final NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Nfc/nxp/src/com/android/nfc/dhimpl/NativeNfcManager.java

Rule Standard Line number
ERR08-J CERT 88

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 88 catch block contains a null pointer exception NullPointerException npe

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Nfc/src/com/android/nfc/beam/BeamSendService.java

Rule Standard Line number
OBJ10-J CERT 36

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 36 code block public static String EXTRA_BEAM_TRANSFER_RECORD="com.android.nfc.beam.EXTRA_BEAM_TRANSFER_RECORD"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Nfc/src/com/android/nfc/beam/BeamTransferManager.java

Rule Standard Line number
FIO02-J CERT 271

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 271 code block file.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 407

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 407 code block srcFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 407

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 407 code block srcFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 407

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 407 code block srcFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 407

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 407 code block srcFile.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Nfc/src/com/android/nfc/beam/BeamTransferRecord.java

Rule Standard Line number
OBJ10-J CERT 26

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 26 code block public static int DATA_LINK_TYPE_BLUETOOTH=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Nfc/src/com/android/nfc/beam/FireflyRenderer.java

Rule Standard Line number
ERR07-J CERT 284

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 284 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Nfc/src/com/android/nfc/handover/HandoverDataParser.java

Rule Standard Line number
MSC02-J CERT 96

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 96 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Nfc/src/com/android/nfc/NfcService.java

Rule Standard Line number
ERR05-J CERT 542

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 542 A method invocation watchDog.cancel() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 539

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 539 A method invocation mRoutingWakeLock.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1482

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1482 A method invocation watchDog.cancel() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1958

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1958 A method invocation mRoutingWakeLock.release() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Nfc/src/com/android/nfc/RegisteredComponentCache.java

Rule Standard Line number
ERR05-J CERT 194

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 194 A method invocation parser.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/OneTimeInitializer/src/com/android/onetimeinitializer/OneTimeInitializerService.java

Rule Standard Line number
ERR05-J CERT 153

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 153 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/PackageInstaller/src/com/android/packageinstaller/InstallFlowAnalytics.java

Rule Standard Line number
ERR05-J CERT 469

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 469 A method invocation EventLogTags.writeInstallPackageAttempt(resultAndFlags,totalElapsedTime,elapsedTimeTillPackageInfoObtained,elapsedTimeTillInstallButtonClick,digestHex) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 587

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 587 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 599

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 599 A method invocation IoUtils.closeQuietly(in) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/PhoneCommon/src/com/android/phone/common/CallLogAsync.java

Rule Standard Line number
ERR07-J CERT 113

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 113 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/QuickSearchBox/benchmarks/src/com/android/quicksearchbox/benchmarks/SourceLatency.java

Rule Standard Line number
ERR07-J CERT 62

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 62 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 155

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 155 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 256

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 256 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/QuickSearchBox/src/com/android/quicksearchbox/QsbApplication.java

Rule Standard Line number
ERR07-J CERT 96

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 96 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/QuickSearchBox/src/com/android/quicksearchbox/util/BarrierConsumer.java

Rule Standard Line number
ERR05-J CERT 68

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 68 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 87

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 87 A method invocation mLock.unlock() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/QuickSearchBox/src/com/android/quicksearchbox/util/Consumers.java

Rule Standard Line number
ERR05-J CERT 34

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 34 A method invocation value.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/QuickSearchBox/src/com/android/quicksearchbox/util/JavaNetHttpHelper.java

Rule Standard Line number
ERR05-J CERT 91

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 91 A method invocation c.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 122

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 122 A method invocation c.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/QuickSearchBox/src/com/android/quicksearchbox/util/SQLiteTransaction.java

Rule Standard Line number
ERR05-J CERT 45

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 45 A method invocation db.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/QuickSearchBox/src/com/android/quicksearchbox/EventLogLogger.java

Rule Standard Line number
MSC02-J CERT 45

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 45 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/accessibility/AccessibilityUtils.java

Rule Standard Line number
ERR05-J CERT 75

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 75 A method invocation res.updateConfiguration(config,null) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/accounts/AccountSyncSettings.java

Rule Standard Line number
EXP02-J CERT 490

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 490 code block accounts[i].equals(account) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/accounts/AddAccountSettings.java

Rule Standard Line number
ERR05-J CERT 120

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 120 A method invocation finish() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/inputmethod/UserDictionaryAddWordActivity.java

Rule Standard Line number
ERR07-J CERT 53

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 53 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/inputmethod/UserDictionaryAddWordContents.java

Rule Standard Line number
ERR05-J CERT 193

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 193 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/inputmethod/UserDictionaryList.java

Rule Standard Line number
ERR05-J CERT 99

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 99 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/search/Index.java

Rule Standard Line number
ERR05-J CERT 388

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 388 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 580

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 580 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 643

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 643 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 917

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 917 A method invocation parser.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 838

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 838 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 913

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 913 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 915

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 915 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR05-J CERT 1198

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1198 A method invocation database.endTransaction() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1284

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1284 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/search/IndexDatabaseHelper.java

Rule Standard Line number
ERR05-J CERT 212

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 212 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/search/Ranking.java

Rule Standard Line number
OBJ10-J CERT 90

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 90 code block public static int sCurrentBaseRank=BASE_RANK_DEFAULT; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/search/SearchIndexableResources.java

Rule Standard Line number
OBJ10-J CERT 62

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 62 code block public static int NO_DATA_RES_ID=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/SettingsActivity.java

Rule Standard Line number
ERR05-J CERT 1217

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1217 A method invocation parser.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 1076

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1076 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1213

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1213 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1215

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1215 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/DeviceInfoSettings.java

Rule Standard Line number
ERR05-J CERT 366

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 366 A method invocation reader.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/DreamBackend.java

Rule Standard Line number
ERR05-J CERT 274

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 274 A method invocation parser.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/users/EditUserPhotoController.java

Rule Standard Line number
ERR05-J CERT 316

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 316 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
FIO02-J CERT 325

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 325 code block fullPath.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

FIO02-J CERT 325

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 325 code block fullPath.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/users/UserDetailsSettings.java

Rule Standard Line number
ERR07-J CERT 90

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 90 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 115

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 115 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/Utils.java

Rule Standard Line number
ERR05-J CERT 546

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 546 A method invocation localRawProfile.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 568

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 568 A method invocation structuredName.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 584

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 584 A method invocation profile.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/vpn2/ConfigDialog.java

Rule Standard Line number
DCL02-J CERT 310

DCL02-J. Do not modify the collection's elements during an enhanced for statement

Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement. Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.

In the given program line number 310 code block contains address trying to modify the collection's elements during an enhanced for statement

Non-compliant Solution

This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:

 
List list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;
 
System.out.println("Processing list...");
for (Integer i: list) {
  if (first) {
    first = false;
    i = new Integer(99);
  }
  System.out.println(" New item: " + i);
  // Process i
}
 
System.out.println("Modified list?");
for (Integer i: list) {
  System.out.println("List item: " + i);
}
 

Compliant Solution

This compliant solution processes the "modified" list but leaves the actual list unchanged:

 
// ...
 
for (final Integer i: list) {
  Integer item = i;
  if (first) {
    first = false;
    item = new Integer(99);
  }
  System.out.println(" New item: " + item);
  // Process item
}
 
// ...
 

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/widget/ExploreByTouchHelper.java

Rule Standard Line number
ERR07-J CERT 295

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 295 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 386

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 386 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 392

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 392 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 398

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 398 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 402

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 402 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/widget/MatchParentShrinkingLinearLayout.java

Rule Standard Line number
ERR07-J CERT 472

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 472 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 486

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 486 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 738

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 738 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/wifi/WifiStatusTest.java

Rule Standard Line number
ERR05-J CERT 410

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 410 A method invocation urlConnection.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/net/ChartDataLoader.java

Rule Standard Line number
ERR07-J CERT 82

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 82 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/notification/NotificationSettings.java

Rule Standard Line number
ERR05-J CERT 367

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 367 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/notification/ZenModeEventRuleSettings.java

Rule Standard Line number
ERR05-J CERT 203

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 203 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/sim/SimDialogActivity.java

Rule Standard Line number
OBJ10-J CERT 51

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 51 code block public static String PREFERRED_SIM="preferred_sim"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 52

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 52 code block public static String DIALOG_TYPE_KEY="dialog_type"; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/TrustAgentUtils.java

Rule Standard Line number
ERR05-J CERT 108

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 108 A method invocation parser.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/applications/RunningServiceDetails.java

Rule Standard Line number
FIO02-J CERT 158

FIO02-J. Detect and handle file-related errors

Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O.

In the given program line number 158 code block filename.delete(); trying to delete file without detect and handle file-related errors

Non-compliant Solution

This noncompliant code example attempts to delete a specified file but gives no indication of its success.

 
 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
	file.delete();
}
	}
	
 

Compliant Solution

This compliant solution checks the return value of delete()

 class FileDelete {
	public static void main(String args[]){
		File file = new File("file");
if (!file.delete()) {
  System.out.println("Deletion failed");
}
	}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/applications/InstalledAppDetails.java

Rule Standard Line number
ERR07-J CERT 277

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 277 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/AppListPreference.java

Rule Standard Line number
OBJ10-J CERT 195

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 195 code block public static Creator CREATOR=new Creator(){ @Override public SavedState createFromParcel( Parcel source){ CharSequence[] entryValues=source.readCharSequenceArray(); CharSequence value=source.readCharSequence(); boolean showItemNone=source.readInt() != 0; Parcelable superState=source.readParcelable(getClass().getClassLoader()); return new SavedState(entryValues,value,showItemNone,superState); } @Override public SavedState[] newArray( int size){ return new SavedState[size]; } } ; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/CredentialStorage.java

Rule Standard Line number
ERR05-J CERT 360

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 360 A method invocation keyChainConnection.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/DataUsageSummary.java

Rule Standard Line number
ERR07-J CERT 334

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 334 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 2602

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 2602 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/RadioInfo.java

Rule Standard Line number
ERR05-J CERT 768

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 768 A method invocation urlConnection.disconnect() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Settings/src/com/android/settings/location/SettingsInjector.java

Rule Standard Line number
ERR05-J CERT 196

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 196 A method invocation parser.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 223

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 223 A method invocation sa.recycle() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/SpeechRecorder/src/com/android/speechrecorder/SpeechRecorderActivity.java

Rule Standard Line number
ERR05-J CERT 225

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 225 A method invocation mBaos.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Stk/src/com/android/stk/StkAppService.java

Rule Standard Line number
ERR07-J CERT 1006

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1006 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR08-J CERT 1705

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 1705 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Stk/src/com/android/stk/StkLauncherActivity.java

Rule Standard Line number
ERR08-J CERT 153

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 153 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Stk/src/com/android/stk/StkMenuActivity.java

Rule Standard Line number
ERR08-J CERT 467

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 467 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Tag/canon/src/com/android/apps/tagcanon/TagCanon.java

Rule Standard Line number
ERR07-J CERT 102

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 102 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 115

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 115 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/Terminal/src/com/android/terminal/TerminalActivity.java

Rule Standard Line number
ERR07-J CERT 71

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 71 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/QuickSettings/src/com/android/tv/quicksettings/PresetSettingsListener.java

Rule Standard Line number
ERR05-J CERT 65

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 65 A method invocation prefs.apply() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/device/display/daydream/DreamInfoAction.java

Rule Standard Line number
OBJ10-J CERT 98

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 98 code block public static Parcelable.Creator CREATOR=new Parcelable.Creator(){ @Override public DreamInfoAction createFromParcel( Parcel source){ return new DreamInfoAction((ResolveInfo)source.readParcelable(null),source.readInt() == 1,source.readString(),(ComponentName)source.readParcelable(null),(ComponentName)source.readParcelable(null)); } @Override public DreamInfoAction[] newArray( int size){ return new DreamInfoAction[size]; } } ; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 184

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 184 A method invocation parser.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/device/display/daydream/NoneDreamInfoAction.java

Rule Standard Line number
OBJ10-J CERT 43

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 43 code block @SuppressWarnings("hiding") public static Parcelable.Creator CREATOR=new Parcelable.Creator(){ @Override public NoneDreamInfoAction createFromParcel( Parcel source){ return new NoneDreamInfoAction(source.readString(),source.readInt() == 1); } @Override public NoneDreamInfoAction[] newArray( int size){ return new NoneDreamInfoAction[size]; } } ; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/accessories/BluetoothDevicePairer.java

Rule Standard Line number
ERR07-J CERT 446

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 446 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/connectivity/AdvancedWifiOptionsFlow.java

Rule Standard Line number
ERR08-J CERT 315

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 315 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 323

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 323 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

ERR08-J CERT 331

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 331 catch block contains a null pointer exception NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/connectivity/setup/SelectFromListWizardFragment.java

Rule Standard Line number
OBJ10-J CERT 130

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 130 code block public static Parcelable.Creator CREATOR=new Parcelable.Creator(){ @Override public ListItem createFromParcel( Parcel source){ ScanResult scanResult=(ScanResult)source.readParcelable(ScanResult.class.getClassLoader()); if (scanResult == null) { return new ListItem(source.readString(),source.readInt()); } else { return new ListItem(scanResult); } } @Override public ListItem[] newArray( int size){ return new ListItem[size]; } } ; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/dialog/DialogFragment.java

Rule Standard Line number
OBJ10-J CERT 1228

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 1228 code block public static Parcelable.Creator CREATOR=new Parcelable.Creator(){ @Override public Action createFromParcel( Parcel source){ return new Action.Builder().key(source.readString()).title(source.readString()).description(source.readString()).intent((Intent)source.readParcelable(Intent.class.getClassLoader())).resourcePackageName(source.readString()).drawableResource(source.readInt()).iconUri((Uri)source.readParcelable(Uri.class.getClassLoader())).checked(source.readInt() != 0).multilineDescription(source.readInt() != 0).checkSetId(source.readInt()).build(); } @Override public Action[] newArray( int size){ return new Action[size]; } } ; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/dialog/old/Action.java

Rule Standard Line number
OBJ10-J CERT 322

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 322 code block public static Parcelable.Creator CREATOR=new Parcelable.Creator(){ @Override public Action createFromParcel( Parcel source){ return new Action.Builder().key(source.readString()).title(source.readString()).description(source.readString()).intent((Intent)source.readParcelable(Intent.class.getClassLoader())).resourcePackageName(source.readString()).drawableResource(source.readInt()).iconUri((Uri)source.readParcelable(Uri.class.getClassLoader())).checked(source.readInt() != 0).multilineDescription(source.readInt() != 0).checkSetId(source.readInt()).build(); } @Override public Action[] newArray( int size){ return new Action[size]; } } ; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/system/CaptionPreviewFragment.java

Rule Standard Line number
ERR05-J CERT 167

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 167 A method invocation res.updateConfiguration(config,null) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/system/CaptionSetupActivity.java

Rule Standard Line number
EXP02-J CERT 757

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 757 code block s.equals(a[i]) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/system/DeveloperOptionsActivity.java

Rule Standard Line number
ERR02-J CERT 820

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 820 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 1041

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 1041 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/util/AccountImageChangeObserver.java

Rule Standard Line number
ERR05-J CERT 185

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 185 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/util/AccountImageHelper.java

Rule Standard Line number
ERR05-J CERT 80

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 80 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/util/bluetooth/BluetoothScanner.java

Rule Standard Line number
ERR07-J CERT 109

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 109 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 207

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 207 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/widget/BitmapDownloader.java

Rule Standard Line number
ERR07-J CERT 261

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 261 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/widget/BitmapWorkerOptions.java

Rule Standard Line number
ERR07-J CERT 100

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 100 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/widget/BitmapWorkerTask.java

Rule Standard Line number
ERR05-J CERT 254

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 254 A method invocation bufferedStream.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/widget/picker/PickerColumn.java

Rule Standard Line number
OBJ10-J CERT 46

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 46 code block public static Parcelable.Creator CREATOR=new Parcelable.Creator(){ @Override public PickerColumn createFromParcel( Parcel source){ return new PickerColumn(source); } @Override public PickerColumn[] newArray( int size){ return new PickerColumn[size]; } } ; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/TvSettings/Settings/src/com/android/tv/settings/widget/ScrollAdapterView.java

Rule Standard Line number
ERR07-J CERT 2914

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 2914 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/emailcommon/internet/MimeHeader.java

Rule Standard Line number
EXP02-J CERT 80

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 80 code block field.name.equalsIgnoreCase(name) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

DCL00-J CERT 93

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 93 have DCL00-J because field.name.equalsIgnoreCase(name) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/emailcommon/internet/MimeUtility.java

Rule Standard Line number
ERR05-J CERT 355

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 355 A method invocation out.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/emailcommon/mail/Base64Body.java

Rule Standard Line number
ERR05-J CERT 60

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 60 A method invocation mSource.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/emailcommon/TempDirectory.java

Rule Standard Line number
ERR07-J CERT 36

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 36 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/browse/MessageHeaderView.java

Rule Standard Line number
DCL02-J CERT 1350

DCL02-J. Do not modify the collection's elements during an enhanced for statement

Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement. Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.

In the given program line number 1350 code block contains span trying to modify the collection's elements during an enhanced for statement

Non-compliant Solution

This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:

 
List list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;
 
System.out.println("Processing list...");
for (Integer i: list) {
  if (first) {
    first = false;
    i = new Integer(99);
  }
  System.out.println(" New item: " + i);
  // Process i
}
 
System.out.println("Modified list?");
for (Integer i: list) {
  System.out.println("List item: " + i);
}
 

Compliant Solution

This compliant solution processes the "modified" list but leaves the actual list unchanged:

 
// ...
 
for (final Integer i: list) {
  Integer item = i;
  if (first) {
    first = false;
    item = new Integer(99);
  }
  System.out.println(" New item: " + item);
  // Process item
}
 
// ...
 

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/browse/SendersView.java

Rule Standard Line number
OBJ10-J CERT 74

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 74 code block public static CharSequence sElidedString; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR05-J CERT 211

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 211 A method invocation clearResourceCache() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 245

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 245 A method invocation clearResourceCache() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 264

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 264 A method invocation clearResourceCache() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 314

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 314 A method invocation PRIORITY_LENGTH_MAP_CACHE.release(priorityToLength) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/browse/EmlMessageLoader.java

Rule Standard Line number
ERR05-J CERT 87

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 87 A method invocation file.getName() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/browse/ConversationCursor.java

Rule Standard Line number
ERR05-J CERT 220

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 220 A method invocation underlyingChanged() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 322

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 322 A method invocation Utils.traceEndSection() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
OBJ10-J CERT 1423

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 1423 code block public static String AUTHORITY; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 1424

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 1424 code block public static String sUriPrefix; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/browse/ConversationItemView.java

Rule Standard Line number
DCL02-J CERT 1079

DCL02-J. Do not modify the collection's elements during an enhanced for statement

Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement. Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.

In the given program line number 1079 code block contains sender trying to modify the collection's elements during an enhanced for statement

Non-compliant Solution

This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:

 
List list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;
 
System.out.println("Processing list...");
for (Integer i: list) {
  if (first) {
    first = false;
    i = new Integer(99);
  }
  System.out.println(" New item: " + i);
  // Process i
}
 
System.out.println("Modified list?");
for (Integer i: list) {
  System.out.println("List item: " + i);
}
 

Compliant Solution

This compliant solution processes the "modified" list but leaves the actual list unchanged:

 
// ...
 
for (final Integer i: list) {
  Integer item = i;
  if (first) {
    first = false;
    item = new Integer(99);
  }
  System.out.println(" New item: " + item);
  // Process item
}
 
// ...
 

Additional information

DCL02-J CERT 1079

DCL02-J. Do not modify the collection's elements during an enhanced for statement

Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement. Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.

In the given program line number 1079 code block contains sender trying to modify the collection's elements during an enhanced for statement

Non-compliant Solution

This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:

 
List list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;
 
System.out.println("Processing list...");
for (Integer i: list) {
  if (first) {
    first = false;
    i = new Integer(99);
  }
  System.out.println(" New item: " + i);
  // Process i
}
 
System.out.println("Modified list?");
for (Integer i: list) {
  System.out.println("List item: " + i);
}
 

Compliant Solution

This compliant solution processes the "modified" list but leaves the actual list unchanged:

 
// ...
 
for (final Integer i: list) {
  Integer item = i;
  if (first) {
    first = false;
    item = new Integer(99);
  }
  System.out.println(" New item: " + item);
  // Process item
}
 
// ...
 

Additional information

ERR08-J CERT 1393

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 1393 catch block contains a null pointer exception final NullPointerException e

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/compose/AttachmentsView.java

Rule Standard Line number
ERR05-J CERT 247

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 247 A method invocation metadataCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 265

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 265 A method invocation metadataCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 279

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 279 A method invocation metadataCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 339

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 339 A method invocation LogUtils.w(LOG_TAG,"Error closing file opened to obtain size.") is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/compose/ComposeActivity.java

Rule Standard Line number
MSC02-J CERT 226

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 226 code block new Random(System.currentTimeMillis()) trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines

ERR05-J CERT 746

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 746 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
DCL00-J CERT 2385

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 2385 have DCL00-J because enableSave(mInnerSavedState != null ? mInnerSavedState.getBoolean(EXTRA_SAVE_ENABLED) : (Intent.ACTION_SEND.equals(action) || Intent.ACTION_SEND_MULTIPLE.equals(action) || Intent.ACTION_SENDTO.equals(action)|| isDraftDirty())) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

ERR05-J CERT 2605

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2605 A method invocation closeOpenedAttachmentFds(sendOrSaveMessage) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 2598

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 2598 A method invocation messageCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/MailLogService.java

Rule Standard Line number
OBJ10-J CERT 50

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 50 code block /** * This is the top level flag that enables this service. */ public static boolean DEBUG_ENABLED=false; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/preferences/FolderPreferences.java

Rule Standard Line number
ERR05-J CERT 169

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 169 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 193

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 193 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/SenderInfoLoader.java

Rule Standard Line number
ERR05-J CERT 232

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 232 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/AbstractActivityController.java

Rule Standard Line number
ERR05-J CERT 4398

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 4398 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 4420

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 4420 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/AbstractConversationWebViewClient.java

Rule Standard Line number
ERR05-J CERT 119

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 119 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/AbstractHtmlTemplates.java

Rule Standard Line number
ERR05-J CERT 83

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 83 A method invocation in.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/settings/PublicPreferenceActivity.java

Rule Standard Line number
OBJ10-J CERT 36

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 36 code block public static Class sPreferenceActivityClass; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/ConversationViewFragment.java

Rule Standard Line number
ERR05-J CERT 690

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 690 A method invocation e.printStackTrace() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR02-J CERT 684

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 684 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR02-J CERT 690

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 690 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR05-J CERT 1771

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1771 A method invocation cookieCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/ConversationViewState.java

Rule Standard Line number
OBJ10-J CERT 46

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 46 code block public static int NONE=0; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 47

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 47 code block public static int EXPANDED=1; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 48

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 48 code block public static int COLLAPSED=2; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 49

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 49 code block public static int SUPER_COLLAPSED=3; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/SwipeHelper.java

Rule Standard Line number
OBJ10-J CERT 59

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 59 code block public static float ALPHA_FADE_START=0f; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

OBJ10-J CERT 61

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 61 code block public static float ALPHA_TEXT_FADE_START=0.4f; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/ThumbnailLoadTask.java

Rule Standard Line number
ERR05-J CERT 157

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 157 A method invocation LogUtils.e(LOG_TAG,e,"") is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 183

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 183 A method invocation LogUtils.e(LOG_TAG,e,"error attemtping to close input stream") is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/ButteryProgressBar.java

Rule Standard Line number
ERR05-J CERT 99

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 99 A method invocation ta.recycle() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/MailboxSelectionActivity.java

Rule Standard Line number
ERR05-J CERT 198

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 198 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/ui/MaterialSearchSuggestionsList.java

Rule Standard Line number
ERR05-J CERT 139

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 139 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/utils/AccountUtils.java

Rule Standard Line number
ERR05-J CERT 88

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 88 A method invocation accountsCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 113

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 113 A method invocation accountsCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/utils/HtmlSanitizer.java

Rule Standard Line number
ERR05-J CERT 405

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 405 A method invocation Timer.stopTiming("sanitizingHTMLEmail") is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/utils/NotificationUtils.java

Rule Standard Line number
ERR05-J CERT 248

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 248 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 268

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 268 A method invocation folderCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
DCL00-J CERT 440

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 440 have DCL00-J because folder.folderUri.equals(notification.account.settings.defaultInbox) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

ERR05-J CERT 833

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 833 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
DCL00-J CERT 678

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 678 have DCL00-J because folder.folderUri.equals(account.settings.defaultInbox) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

DCL00-J CERT 983

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 983 have DCL00-J because folder.folderUri.fullUri.equals(account.settings.defaultInbox) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

ERR05-J CERT 1126

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1126 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1327

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1327 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
DCL02-J CERT 1390

DCL02-J. Do not modify the collection's elements during an enhanced for statement

Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement. Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.

In the given program line number 1390 code block contains sender trying to modify the collection's elements during an enhanced for statement

Non-compliant Solution

This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:

 
List list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;
 
System.out.println("Processing list...");
for (Integer i: list) {
  if (first) {
    first = false;
    i = new Integer(99);
  }
  System.out.println(" New item: " + i);
  // Process i
}
 
System.out.println("Modified list?");
for (Integer i: list) {
  System.out.println("List item: " + i);
}
 

Compliant Solution

This compliant solution processes the "modified" list but leaves the actual list unchanged:

 
// ...
 
for (final Integer i: list) {
  Integer item = i;
  if (first) {
    first = false;
    item = new Integer(99);
  }
  System.out.println(" New item: " + item);
  // Process item
}
 
// ...
 

Additional information

DCL02-J CERT 1390

DCL02-J. Do not modify the collection's elements during an enhanced for statement

Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement. Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.

In the given program line number 1390 code block contains sender trying to modify the collection's elements during an enhanced for statement

Non-compliant Solution

This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:

 
List list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;
 
System.out.println("Processing list...");
for (Integer i: list) {
  if (first) {
    first = false;
    i = new Integer(99);
  }
  System.out.println(" New item: " + i);
  // Process i
}
 
System.out.println("Modified list?");
for (Integer i: list) {
  System.out.println("List item: " + i);
}
 

Compliant Solution

This compliant solution processes the "modified" list but leaves the actual list unchanged:

 
// ...
 
for (final Integer i: list) {
  Integer item = i;
  if (first) {
    first = false;
    item = new Integer(99);
  }
  System.out.println(" New item: " + item);
  // Process item
}
 
// ...
 

Additional information

DCL00-J CERT 1396

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 1396 have DCL00-J because SendersView.sElidedString.equals(sender.toString()) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

DCL00-J CERT 1648

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 1648 have DCL00-J because account.equals(key.account.getAccountManagerAccount()) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

ERR05-J CERT 1765

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1765 A method invocation c.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1802

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1802 A method invocation Closeables.closeQuietly(inputStream) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
DCL00-J CERT 1922

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 1922 have DCL00-J because account.getAccountManagerAccount().equals(key.account.getAccountManagerAccount()) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

DCL00-J CERT 1923

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 1923 have DCL00-J because folder.equals(key.folder) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/utils/Utils.java

Rule Standard Line number
ERR05-J CERT 1005

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1005 A method invocation cursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/widget/BaseWidgetProvider.java

Rule Standard Line number
EXP02-J CERT 167

EXP02-J. Do not use the Object.equals() method to compare two arrays

n Java, arrays are objects and support object methods such as Object.equals(). However, arrays do not support any methods besides those provided by Object. Consequently, using Object.equals() on any array compares only array references, not their contents. Programmers who wish to compare the contents of two arrays must use the static two-argument Arrays.equals() method. This method considers two arrays equivalent if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equivalent, according to Object.equals(). In other words, two arrays are equal if they contain equivalent elements in the same order. To test for reference equality, use the reference equality operators, == and !=. Because the effect of using Object.equals() to compare two arrays is often misconstrued as content equality, and because a better alternative exists in the use of reference equality operators, the use of the Object.equals() method to compare two arrays is disallowed.

In the given program line number 167 code block TextUtils.equals(accountUri.toString(),parsedInfo[0]) trying to

Non-compliant Solution

This noncompliant code example uses the Object.equals() method to compare two arrays:

 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(arr1.equals(arr2)); // Prints false
 

Compliant Solution

This compliant solution compares the content of two arrays using the two-argument Arrays.equals() method:

 
 
int[] arr1 = new int[20]; // Initialized to 0
int[] arr2 = new int[20]; // Initialized to 0
System.out.println(Arrays.equals(arr1, arr2)); // Prints true
 

Additional information

Related Guidelines

DCL00-J CERT 170

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 170 have DCL00-J because TextUtils.equals(folderUri.toString(),parsedInfo[1]) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

ERR05-J CERT 254

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 254 A method invocation folderCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 286

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 286 A method invocation accountCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 380

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 380 A method invocation folderCursor.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/android/mail/widget/WidgetService.java

Rule Standard Line number
DCL02-J CERT 457

DCL02-J. Do not modify the collection's elements during an enhanced for statement

Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement. Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.

In the given program line number 457 code block contains sender trying to modify the collection's elements during an enhanced for statement

Non-compliant Solution

This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:

 
List list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;
 
System.out.println("Processing list...");
for (Integer i: list) {
  if (first) {
    first = false;
    i = new Integer(99);
  }
  System.out.println(" New item: " + i);
  // Process i
}
 
System.out.println("Modified list?");
for (Integer i: list) {
  System.out.println("List item: " + i);
}
 

Compliant Solution

This compliant solution processes the "modified" list but leaves the actual list unchanged:

 
// ...
 
for (final Integer i: list) {
  Integer item = i;
  if (first) {
    first = false;
    item = new Integer(99);
  }
  System.out.println(" New item: " + item);
  // Process item
}
 
// ...
 

Additional information

DCL02-J CERT 457

DCL02-J. Do not modify the collection's elements during an enhanced for statement

Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement. Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.

In the given program line number 457 code block contains sender trying to modify the collection's elements during an enhanced for statement

Non-compliant Solution

This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:

 
List list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;
 
System.out.println("Processing list...");
for (Integer i: list) {
  if (first) {
    first = false;
    i = new Integer(99);
  }
  System.out.println(" New item: " + i);
  // Process i
}
 
System.out.println("Modified list?");
for (Integer i: list) {
  System.out.println("List item: " + i);
}
 

Compliant Solution

This compliant solution processes the "modified" list but leaves the actual list unchanged:

 
// ...
 
for (final Integer i: list) {
  Integer item = i;
  if (first) {
    first = false;
    item = new Integer(99);
  }
  System.out.println(" New item: " + item);
  // Process item
}
 
// ...
 

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/google/android/mail/common/base/StringUtil.java

Rule Standard Line number
OBJ10-J CERT 1462

OBJ10-J. Do not use public static nonfinal fields

There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to null.

In the given program line number 1462 code block /** * Represents the type of javascript escaping to perform. Each enum below * determines whether to use octal escapes and how to handle quotes. */ public static enum JsEscapingMode; trying to use public static nonfinal fields

Non-compliant Solution

This non-compliant declares a function table containing a public static field.

 
 public class Greeter {
  public static Foo foo = new Foo();
  ...
}
 

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:

 
 public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
 

Additional information

Related Guidelines

ERR07-J CERT 1487

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1487 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 1660

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 1660 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
DCL00-J CERT 2381

DCL00-J. Prevent class initialization cycles

Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Therefore, the presence of a static field triggers the initialization of a class. However, the initializer of a static field could depend on the initialization of another class, possibly creating an initialization cycle.\cite{CERT}. There are two types of class initialization cycle problem, Intraclass and interclass. In intraclass the vulnerability happened because the constructor invocation is done before completing the initialization of the variables. The solution is, do the object creation after the complete variable initialization.

In the given program line number 2381 have DCL00-J because Character.UnicodeBlock.HEBREW.equals(Character.UnicodeBlock.of(codePoint)) trying to

Non-compliant Solution

In the non-compliant code, there is a static final variable initialization after class object creation.

 
public class RollNo {
private final int idNumber;
private static final RollNo r= new RollNo();
private static final int seed = (int) (Math.random() * 100);
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Compliant Solution

In the compliant code, the static final variable initialization done before class object creation.

 
public class RollNo {
private final int idNumber;
private static final int seed = (int) (Math.random() * 100);
private static final RollNo r= new RollNo();
public RollNo() {
idNumber = seed - 10;
}
public static void main(String[] args) {
System.out.println("Your unique id is: " + r.idNumber);
}
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/com/google/android/mail/common/base/X.java

Rule Standard Line number
ERR07-J CERT 47

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 47 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 57

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 57 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/commons/io/FileSystemUtils.java

Rule Standard Line number
ERR05-J CERT 442

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 442 A method invocation proc.destroy() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/commons/io/FileUtils.java

Rule Standard Line number
ERR05-J CERT 453

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 453 A method invocation IOUtils.closeQuietly(input2) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 681

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 681 A method invocation IOUtils.closeQuietly(input) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 678

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 678 A method invocation IOUtils.closeQuietly(output) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 965

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 965 A method invocation IOUtils.closeQuietly(input) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 962

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 962 A method invocation IOUtils.closeQuietly(output) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1109

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1109 A method invocation IOUtils.closeQuietly(in) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1142

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1142 A method invocation IOUtils.closeQuietly(in) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1163

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1163 A method invocation IOUtils.closeQuietly(in) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1257

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1257 A method invocation IOUtils.closeQuietly(out) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1289

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1289 A method invocation IOUtils.closeQuietly(out) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1348

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1348 A method invocation IOUtils.closeQuietly(out) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 1712

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 1712 A method invocation IOUtils.closeQuietly(in) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/commons/io/input/TeeInputStream.java

Rule Standard Line number
ERR05-J CERT 93

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 93 A method invocation branch.close() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/commons/io/output/DeferredFileOutputStream.java

Rule Standard Line number
ERR05-J CERT 265

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 265 A method invocation IOUtils.closeQuietly(fis) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/commons/io/output/LockableFileWriter.java

Rule Standard Line number
ERR05-J CERT 271

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 271 A method invocation lockFile.delete() is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/james/mime4j/field/address/AddressList.java

Rule Standard Line number
ERR02-J CERT 133

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 133 code block e.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/james/mime4j/field/address/parser/AddressListParser.java

Rule Standard Line number
ERR02-J CERT 27

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 27 code block x.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR05-J CERT 129

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 129 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 187

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 187 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 233

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 233 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 264

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 264 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 327

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 327 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 367

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 367 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 425

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 425 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 464

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 464 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 496

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 496 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 558

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 558 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 608

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 608 A method invocation jjtreeCloseNodeScope(jjtn000) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 617

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 617 A method invocation jj_save(0,xla) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR05-J CERT 624

ERR05-J. Do not let checked exceptions escape from a finally block

Methods invoked from within a finally block can throw an exception. Failure to catch and handle such exceptions results in the abrupt termination of the entire try block. Abrupt termination causes any exception thrown in the try block to be lost, preventing any possible recovery method from handling that specific problem.

In the given program line number 624 A method invocation jj_save(1,xla) is present inside a finally block without a try-catch block

Non-compliant Solution

This noncompliant code example contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions and consequently fails to appropriately handle any exception that may arise.

 
 try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        reader.close();
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
 

Compliant Solution

This compliant solution encloses the close() method invocation in a try-catch block of its own within the finally block. Consequently, the potential IOException can be handled without allowing it to propagate further.t

 
  try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations
      } finally {
        try {
          reader.close();
        } catch (IOException ie) {
          // Forward to handler
        }
        // ... Other cleanup code ...
      }
    } catch (IOException x) {
      // Forward to handler
    }
    

Additional information

Related Guidelines

  • CWE-703, Improper Check or Handling of Exceptional Conditions
  • CWE-248, Uncaught Exception
ERR07-J CERT 728

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 728 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 741

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 741 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/james/mime4j/field/contenttype/parser/ContentTypeParser.java

Rule Standard Line number
ERR02-J CERT 40

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 40 code block x.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR07-J CERT 133

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 133 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 145

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 145 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/james/mime4j/field/ContentTypeField.java

Rule Standard Line number
ERR08-J CERT 254

ERR08-J. Do not catch NullPointerException or any of its ancestors

NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.

In the given program line number 254 catch block contains a null pointer exception NullPointerException npe

Non-compliant Solution

In the Non-compliant Solution rather than checking to see whether the given string is null, the method catches NullPointerException and returns false.

 
public int lengthPlus(String str) {
  int len = 2;
  try {
    len += str.length();
  }
  catch (NullPointerException e) {
    log.info("argument was null");
  }
  return len;
}
 

Compliant Solution

This compliant solution explicitly checks the String argument for null rather than catching NullPointerException:

 
 public int lengthPlus(String str) {
  int len = 2;

  if (str != null) {
    len += str.length();
  }
  else {
    log.info("argument was null");
  }
  return len;
}

Additional information

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/james/mime4j/field/datetime/parser/DateTimeParser.java

Rule Standard Line number
ERR02-J CERT 32

ERR02-J. Prevent exceptions while logging data

When logging a message there are several important requirements which must be fulfilled:

  • The user must be able to easily retrieve the logs
  • The format of all logged message must be uniform to allow the user to easily read the log
  • Logged data must actually be recorded
  • Sensitive data must only be logged securely
If a program directly writes to the standard outputs, there is absolutely no way to comply with those requirements. That's why defining and using a dedicated logger is highly recommended.

In the given program line number 32 code block x.printStackTrace() trying to

Non-compliant Solution

his noncompliant code example writes a critical security exception to the standard error stream.Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security-critical exceptions or errors without leaking sensitive information. If an I/O error were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions. Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

 
try {
  // ...
} catch (SecurityException se) {
  System.err.println(se);
  // Recover from exception
}
 

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

 try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

Additional information

Related Guidelines

ERR07-J CERT 432

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 432 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception
ERR07-J CERT 444

ERR07-J. Do not throw RuntimeException, Exception, or Throwable

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

Methods must not throw RuntimeException, Exception, or Throwable. Throwing a RuntimeException can lead to subtle errors; for example, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.

In the given program line number 444 throws RuntimeException

Non-compliant Solution

The isCapitalized() method in this noncompliant code example accepts a string and returns true when the string consists of a capital letter followed by lowercase letters. The method also throws a RuntimeException when passed a null string argument.

 
boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}
 

Compliant Solution

This compliant solution throws NullPointerException to denote the specific exceptional condition


  boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  if (s.equals("")) {
    return true;
  }
  String first = s.substring(0, 1);
  String rest = s.substring(1);
  return (first.equals(first.toUpperCase()) &&
          rest.equals(rest.toLowerCase()));
}

Additional information

Related Guidelines

  • CWE-397, Declaration of Throws for Generic Exception

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/james/mime4j/RootInputStream.java

Rule Standard Line number
NUM09-J CERT 96

NUM09-J. Do not use floating-point variables as loop counters

Floating-point variables must not be used as loop counters. Limited-precision IEEE 754 floating-point types cannot represent

  • All simple fractions exactly.
  • All decimals precisely, even when the decimals can be represented in a small number of digits.
  • All digits of large values, meaning that incrementing a large floating-point value might not change that value within the available precision.

In the given program line number 96 code block Do not use floating-point variables as loop counters ' i < off + n contains a floating-point variables as loop counters.

Non-compliant Solution

This noncompliant code example uses a floating-point variable as a loop counter. The decimal number 0.1 cannot be precisely represented as a float or even as a double

 
 for (float x = 0.1f; x <= 1.0f; x += 0.1f) {
  System.out.println(x);
}
 

Compliant Solution

This compliant solution uses an integer loop counter from which the desired floating-point value is derived:

 
 
for (int count = 1; count <= 10; count += 1) {
  float x = count/10.0f;
  System.out.println(x);
}
 

Additional information

Related Guidelines

Location :/media/rahul/Education/Project/src/M/Sources/packages/apps/UnifiedEmail/src/org/apache/james/mime4j/util/SimpleTempStorage.java

Rule Standard Line number
MSC02-J CERT 45

MSC02-J. Generate strong random numbers

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information. As the java.util.Random class relies on a pseudorandom number generator, this class and relating java.lang.Math.random() method should not be used for security-critical applications or for protecting sensitive data. In such context, the java.security.SecureRandom class which relies on a cryptographically strong random number generator (RNG) should be used in place.

In the given program line number 45 code block new Random() trying to

Non-compliant Solution

This noncompliant code example uses the insecure java.util.Random class. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.

 
 
import java.util.Random;
// ...
 
Random number = new Random(123L);
//...
for (int i = 0; i < 20; i++) {
  // Generate another random integer in the range [0, 20]
  int n = number.nextInt(21);
  System.out.println(n);
}
 

Compliant Solution

This compliant solution uses the java.security.SecureRandom class to produce high-quality random numbers:

 
 
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
 
public static void main (String args[]) {
  SecureRandom number = new SecureRandom();
  // Generate 20 integers 0..20
  for (int i = 0; i < 20; i++) {
    System.out.println(number.nextInt(21));
  }
}
 

Additional information

Related Guidelines